[Part 1] System design and software design in distributed systems

When you ask an engineer to provide clear cut definitions of System Design, System Architecture, Software Design, Software Architecture… the conversation suddenly has lots of hand waving, context-specific definitions, and “according to [insert popular engineering book]”.

The truth is that, as with many terms in software engineering, there isn’t a clear-cut, industry-wide definition. That’s because it’s both a broad area of study, but also because it’s a constantly moving target due to the rapidly evolving developments in the tech ecosystem.

Let’s reduce the hand waving

While building Multiplayer, we realized that we were also using these terms interchangeably.

Our mission is to make debugging distributed systems effortless for engineering and support teams, through full-stack, session-based visibility. Therefore, it was inevitable that we would have to define into what our full stack session recordings provide visibility. What do we mean by distributed system? system architecture? components?

Even without clear-cut definitions we would be able to get our point across, after all debugging is a universal activity (and pain point) for engineering teams. Having end-to-end visibility into a technical issue is, to a degree, self-explanatory.

But it's helpful to have a shared language and mental models when describing our product and roadmap. That's why we came up with shared definitions for all these terms, specifically in the context of distributed systems, and we hope you find this useful as well.

There is a lively debate on where the boundaries of each term lie and many smarter people than us have written extensively about it. This is not meant to be a “glossary to rule them all”, but insight into how we think, and talk about, these topics.

Strategic vs Tactical

The best way to think about System Design vs Software Design is not in binary form, but as activities that fall on a spectrum from more strategic to more tactical.

Depending on your use case (e.g. Web Application, Mobile App , Embedded System, etc.) the final architecture and implementation can be very different. In fact, there is no “one-size-fits-all” approach and solution. Expecting a single architecture to work for all use cases, or even most of them, is unrealistic, especially as it will change over time.

There are however, two immutable and universal “laws” that apply to both system and software design:

• Everything is a trade off
• Why is more important than how

Distributed Systems

Distributed Systems, also known as distributed computing, are a collection of multiple independent software components - located on different machines that communicate through a network - that split up the work, coordinating efforts to achieve common goals.

The ultimate goal of a distributed system is to enable the scalability, performance and high availability of applications - in fact, the vast majority of products and applications rely on them nowadays.

The size, complexity, and topology a Distributed System can vary significantly, from as few as three servers to a few thousand servers, making their design, development, and management a unique challenge.

System Design vs Software Design

We explore in detail the definition of system vs software design here:

• System design 101
• Software design 101

As a high-level summary and explanation, lets take a web-based e-commerce application as an example.

• System Design → It would define the System Architecture and its implementation to meet the agreed requirements (e.g. handling user requests, having a product catalog, processing orders and payments).
  • System Architecture Styles → It would clarify that the system should follow a microservices architecture to enable the modularization of functions like user account management, product catalog, and payment processing into distinct services.
  • Distributed System Design Pattern → To address scalability and performance challenges it would implement a "Load Balancer" pattern to distribute incoming web traffic across multiple servers to ensure high availability and handle a large number of concurrent users.
• Software Design → It would focus on defining and implementing the Software Architecture: the overall structure of the software components (e.g., databases, web servers, major software modules), including the separation of concerns. For instance, it would define the separation of the presentation layer (user interface) from the application logic and data storage. It would address how to specifically implement user interface elements like product listings, shopping cart views, and order checkout. It would also address database design for storing user accounts, product data, and order history.
  • Software Architecture Styles → It would use a clean architecture to guide how to organize components, ensuring that high-level policies (e.g., ordering process) are decoupled from low-level details (e.g., database operations).
  • Software Design Patterns → To improve the maintainability and reusability of code, it might apply the "Factory Method" pattern for creating product objects with different attributes (e.g., color, size) and the "Singleton" pattern for ensuring a single instance of a shopping cart is available throughout the user's session.