[Part 2] System design 101

Multiplayer's mission is to make debugging distributed systems effortless for engineering and support teams, through full-stack, session-based visibility.

Our team found that aligning on a shared language into what our full stack session recordings provide visibility is helpful to understand their scope and impact. That's because terms like distributed system, software system, system design, software design, etc. can have broad, overlapping or, sometimes, interchangeable definitions.

This article series explores what these terms mean and how your team can use them to communicate more clearly.

• TL;DR System design vs software design
• System design 101
• Software design 101

System design 101

“A system’s architecture is a representation of a system in which there is a mapping of functionality onto hardware and software components, a mapping of the software architecture onto the hardware architecture, and a concern for the human interaction with these components. That is, system architecture is concerned with the totality of hardware, software and humans.”

- “Software Architecture in Practice” by Len Bass, Paul Clements, and Rick Kazman

System Design is the process of defining the System Architecture and how it will be implemented, to meet the requirements and expected functionality of the application.

In other words, it involves defining the high-level conceptual structure of an entire complex system (System Architecture) and all its major components and interactions, encompassing all aspects of the system (i.e. software, hardware, data, interfaces, and user interactions), to ensure that they work together effectively and efficiently to achieve specific goals.

System Architecture is often intended for a broader audience besides developers: it includes stakeholders, managers, and decision-makers who need to understand the system's design at a conceptual level.

Keep in mind that System Design is an iterative process: it will evolve as the technology ecosystem evolves and as your application requirements change. For the System Architecture Diagrams to be effective tools, they need to be constantly updated and provide a real-time, accurate, and interactive view of your system.

Likewise, all the documentation mentioned should be always up-to-date, thorough and easily accessible - there are few things in the developer world as painful as incorrect or outdated documentation!

Phases in the System Design process

Here are some of the key phases of the System Design process:

• Technology selection: Choosing the appropriate technologies, frameworks, and tools for implementing the system.
• Capacity planning: Estimating the approximate scale of the system. In other words, doing “back of the envelope calculations” about active users, reads vs writes, queries per second, storage, throughput, number of instances required, etc. (Tip: these are numbers every developer should know)
• Scalability and performance analysis: Planning the best approach to accommodating future growth (e.g. vertical vs horizontal scaling), while also implementing strategies for maintaining and optimizing the system's performance, including load balancing, caching, and query optimization.
• Tradeoff analysis: Analyzing the impact of various design choices on the functional and non-functional requirements (e.g. reliability, data Integrity, privacy, etc.) and listing the reasons why certain approaches were discarded or chosen.
• Interface design: Listing out all the key interaction points between the users and the system (e.g. how users can add information, how a system represents information to users, etc.) and the interfaces between different components of the system, including APIs, protocols, and data formats.
• Data design: Defining the system’s data model, how data will flow between the different components and inputs/outputs of a system.
• Risk mitigation: Identifying potential bottlenecks in the system, risk factors and mitigating strategies. This also includes outlining the security practices planned (e.g. authentication, authorization, encryption, and data protection) and listing whether there is any known technical debt incurred by implementing the selected System Architecture.

System Architecture Styles

As with many IT terms, “Architecture Styles” and “Architecture Patterns” are often used as a synonyms:

“An architectural style (Base et al. 1997) and an architectural pattern (Buschmann et al. 1996) are essentially synonymous.”

- Practical Guide to Enterprise Architecture, James McGovern

"We are still far from having a well-accepted taxonomy of such architectural paradigms, let alone a fully-developed theory of software architecture. But we can now clearly identify a number of architectural patterns, or styles, that currently form the basic repertoire of a software architect.”

- An introduction to software architecture, David Garlan and Mary Shaw

However, we’ve opted to distinguish between them and we define Architectural Styles as the overall structure and organization of a software system from a 10k feet view (i.e. it shows the highest level of abstraction of the system design).

Architecture Styles answer fundamental questions such as how the system components communicate, how data flows, and how the system is divided into modules or layers. Changes to Architectural Styles are significant and can be costly: they involve restructuring the fundamental aspects of the system and can have a long-term impact on the project.

System Architecture can often be categorized into two broad paradigms:

• Centralized, which are typically represented by client-server systems
• Decentralized, which are exemplified by peer-to-peer systems.

In this blog post series we delve into the specifics of Architecture Styles such as:

• Monolithic
• Microservices
• Event-Driven
• Serverless
• Edge Computing
• Peer-to-Peer

However, there are many more to explore: Layered, Service-Oriented (SOA), Space-Based, Microkernel, Cell-Based, Cloud computing, etc.

Distributed System Design Patterns

Distributed systems are ubiquitous in modern software and many businesses face common problems related to data storage, messaging, system management, and compute capability, which they solve with similar solutions. These frequently used solutions are considered Distributed System Design Patterns.

For example, here are top seven most-used Distributed System Design Patterns:

• Ambassador
• Circuit Breaker
• CQRS
• Event Sourcing
• Leader Election
• Publisher / Subscriber
• Sharding