Designing Distributed Software With Shared Context

Thomas Johnson and Julian Wood discuss documentation, tracing and team collaboration.

TJThomas JohnsonGuest
Channel
GOTO Conferences
Published
Jun 6, 2025
Video
44:40
Read
2 min
Original
English
Open on YouTube
Scroll to read and the video shrinks to the bottom-right corner. Captions follow your reading language.
Reading languageAvailable in 2 languages
You're reading the original English.
SUMMARY

In 30 seconds

Multiplayer co-founder Thomas Johnson and AWS advocate Julian Wood discuss how teams understand distributed systems, automate documentation, trace problems and review design early. Their product discussion reflects their professional roles.

  1. 1ComplexityServices and dependencies make system knowledge harder to maintain.
  2. 2DocumentationAutomation can help, but generated documentation needs verification.
  3. 3System viewsShared visual views support onboarding and discussion.
  4. 4TracingCorrelated traces can aid cross-service debugging.
  5. 5Early reviewDesign review can happen before the pull request.
  6. 6ReuseUse suitable existing components while considering tradeoffs.
  7. 7Observe usageCustomer usage can reveal unexpected paths.

Takeaways

  1. Services and dependencies make system knowledge harder to maintain.
  2. Automation can help, but generated documentation needs verification.
  3. Shared visual views support onboarding and discussion.
  4. Correlated traces can aid cross-service debugging.
  5. Design review can happen before the pull request.
  6. Use suitable existing components while considering tradeoffs.
  7. Customer usage can reveal unexpected paths.
FULL TEXT

Read the edited text by chapter

Transcript only
01

Understanding distributed systems

Dependencies, documentation and views.

In this GOTO Unscripted interview, AWS developer advocate Julian Wood speaks with Multiplayer co-founder Thomas Johnson about developing and understanding distributed software. Both discuss products and practices connected to their work, and their future predictions are opinions.

Johnson describes how a growing system accumulates services, dependencies and undocumented decisions. The more complex the system, the harder it becomes for a new engineer to understand what exists and why.

The pair discuss documentation generated from code and runtime information. Automation may help keep an architectural view current, but the source data and assumptions still need to be checked.

Johnson argues that visual views of services and dependencies can help teams communicate and onboard. He describes Multiplayer’s approach to building a shared representation from distributed-system data.

02

Tracing and design review

Debugging and early collaboration.

They discuss OpenTelemetry and debugging across service boundaries. Johnson describes correlating traces across a debugging session; sharing operational data between organizations requires appropriate access controls and agreement.

Johnson recommends discussing changes before coding is finished: a design review can involve operations, testing, frontend and backend teams before a pull request becomes the first opportunity for feedback.

03

Building and evolving

Reuse, usage and shared context.

For new systems, they recommend using suitable existing libraries and managed services instead of rebuilding everything, while keeping the design simple enough to evolve. The right boundary depends on cost, control and operational needs.

Wood notes that real usage can differ from architectural expectations. The pair advocate involving customers and partners, observing usage patterns and avoiding premature optimization of the wrong path.

A shared, higher-level workspace can help teams discuss intent and dependencies, but Johnson distinguishes a diagram from the design process itself. The aim is fewer surprises when implementation reaches review.

04

The future of tools

Infrastructure abstraction as a prediction.

Looking ahead, the speakers expect infrastructure to become more abstract and tools to lower the effort of building software. They acknowledge that substantial work remains; this is a forecast, not an established outcome.

More from this channel

3 slides39:12EN
GOTO Conferences· Oct 28, 2026Cate Huston: How Rigour Supports AI-Assisted Development VelocityCate Huston · TwillA two-person team’s experience with release gates, automated checks, prioritization and the cost of shipping faster.AI engineering leadershipSoftware engineeringAI agents
4 slides22:33EN
GOTO Conferences· Oct 26, 2026William Schor: From Unit Tests to Synthetic Canaries at NetflixWilliam Schor · NetflixHow generated workloads and production-like infrastructure help test a distributed key-value service.Software engineering
5 slides34:11EN
GOTO Conferences· Oct 23, 2026Anatoliy Bilenko and Alberto Carretero: Making Database Protocols Reliable with Formal Methods and AIAnatoliy Bilenko, Alberto Carretero · CanonicalCanonical’s database engineers connect executable specifications, model-based tests, failure exploration, and reconstructed execution histories—and explain why none of these techniques proves a real system correct on its own.Developer workflows & testingCode review & verificationObservability & reliability+2
28:15EN
GOTO Conferences· Oct 22, 2026Steve Poole on Open-Source Security and AI’s Maintenance ChallengeOlimpiu Pop, Steve PooleWhy faster vulnerability discovery increases pressure on maintainers, dependency users and upgrade processes.Software engineeringAI security
5 slides46:36EN
GOTO Conferences· Oct 21, 2026Don Syme: Building Agentic Automation Around Human CollaborationDon Syme · GitHubContinuous AI, repository workflows and the guardrails needed for unattended software maintenance.Agent orchestrationSoftware engineeringCoding agents
28:23EN
GOTO Conferences· Oct 19, 2026Learning Ash: Declarative Elixir Apps, Testing and ExtensibilityChristian Alexander, Rebecca Le, Zach DanielRebecca Le and Zach Daniel explain how their book and the framework evolved together.Software engineering