System design

System design is the process of defining how a software system will work at a high level - its architecture, components, data flows, and interfaces. Before writing code, system design establishes the blueprint: how parts of the system will communicate, where data will live, how the system will scale, and how it will handle failure. Good system design enables systems that are maintainable, scalable, and aligned with business needs.

Why it matters

Building software without design is like constructing a building without blueprints. You might create something that works initially, but it will be difficult to modify, prone to problems, and expensive to maintain.

System design matters because it enables scale since well-designed systems can grow without fundamental restructuring. It improves maintainability because clear architecture makes systems easier to understand and modify. It reduces cost since design decisions have long-term implications, with good design reducing rework. It manages complexity because systems become complex, and design provides structure for managing complexity. It aligns with requirements so systems are built to meet actual needs, not assumed ones. And it facilitates communication since design artifacts create shared understanding among team members.

System design elements

Requirements drive design. Functional requirements determine what the system does, and non-functional requirements (performance, security, availability) constrain how. Design that doesn't trace to requirements is guesswork.

Architecture defines the overall structure: the major components and how they relate. Monolithic architecture runs everything in one process, which is simpler to deploy and debug but harder to scale and maintain. Microservices architecture runs separate services for different functions, enabling independent scaling and deployment but adding distributed system complexity. Event-driven architecture has components communicating through events for loose coupling and flexibility, with added complexity in event management. Serverless architecture runs functions on demand without managing servers, enabling easy scaling with execution limits and vendor dependency.

Components are the building blocks with distinct responsibilities: API services, databases, caches, message queues, file storage, and authentication services. Each component has a purpose and interfaces with other components.

Data design addresses how information is stored and flows through the system. Data models determine how data is structured (SQL, NoSQL, graph, time-series). Data flow shows how data moves between components. Data storage places data in databases, files, caches, and archives. Data consistency determines how synchronized data is across components.

Interfaces define how components communicate. APIs specify how services are accessed. Protocols determine HTTP, gRPC, WebSocket, and other communication methods. Contracts establish expected inputs and outputs. Versioning enables interfaces to evolve without breaking consumers.

Infrastructure provides the foundation of compute, storage, and networking. Servers include virtual machines, containers, and serverless functions. Networking includes load balancers, CDNs, and DNS. Storage includes databases, object storage, and file systems. Cloud services provide managed services from AWS, GCP, and Azure.

System design process

Understand requirements first. What must the system do? How many users? What performance is needed? What's the budget? What constraints exist?

Identify components by determining what major pieces are needed. What services? What databases? What external integrations?

Define interactions by mapping how components communicate, what APIs are needed, and how data flows between components.

Consider scale by determining expected load and how the system will handle growth. What's the scaling strategy?

Plan for failure by identifying what can go wrong. How will the system handle component failure? What's the disaster recovery plan?

Document and review by capturing the design in diagrams and documents. Review with stakeholders and iterate.

Common design patterns

Load balancing distributes traffic across multiple servers for horizontal scaling and high availability.

Caching stores frequently accessed data closer to consumers. CDNs cache at the edge, application caches reduce database load, and browser caches reduce network traffic.

Database patterns include replication (copies for availability and read scaling), sharding (partitioning for write scaling), and indexing (optimizing query performance).

Message queues decouple components for async processing, absorbing load spikes and enabling reliable delivery.

API gateway provides a single entry point that handles authentication, rate limiting, routing, and cross-cutting concerns.

Circuit breaker prevents cascading failures when dependencies fail, failing fast rather than waiting for timeout.

Design trade-offs

System design involves trade-offs. CAP theorem states that distributed systems can't simultaneously guarantee consistency (all nodes see the same data), availability (every request gets a response), and partition tolerance (the system works despite network failures). You must choose which to sacrifice.

Latency vs. throughput creates a trade-off between serving individual requests fast (latency) and processing many requests (throughput).

Consistency vs. availability means strong consistency often reduces availability; eventual consistency improves availability but complicates application logic.

Simplicity vs. flexibility means simpler systems are easier to understand but less adaptable; flexible systems handle more cases but are more complex.

Cost vs. performance is real since better performance usually costs more.

System design for product managers

Product managers don't design systems, but understanding system design helps in several ways. Setting realistic expectations means understanding what's feasible and what's hard. Making informed trade-offs means understanding performance, cost, and timeline relationships. Communicating effectively means speaking the same language as engineering. Evaluating proposals means assessing whether technical approaches make sense.

When engineering proposes a design, product managers can ask: How does this meet our requirements? What are the trade-offs? How does it scale? What are the risks?

Tools like Klero connect customer feedback to product decisions, including technical ones. When you can see what customers need and how they use the product, you can better evaluate whether system designs will meet real requirements rather than assumed ones.