Designing Distributed Software With Shared Context

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.

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.

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.

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.