What are some common system design patterns?
The most common system design patterns are cache-aside, primary-replica replication, sharding, load balancing, message queues, publish-subscribe, API gateway, circuit breaker, idempotency, and CQRS.
A system design pattern is a named, reusable solution to a problem that keeps recurring when you build distributed systems. "Reads are overwhelming my database" is a recurring problem, and cache-aside is its named solution. "A retry charged the customer twice" is a recurring problem, and idempotency is its named solution.
Below is what each of the ten solves, the move it makes, and the price you pay for it. Naming the price is the part most people skip, and it is the part that separates understanding a pattern from having read about it.
1. Cache-Aside
Solves: The same expensive read hitting your database thousands of times per second.
The move: The application checks the cache first. On a miss it loads from the database and stores the result with a time-to-live (TTL).
The cost: Cached data goes stale, and invalidation is your responsibility. Two numbers govern the design: the hit ratio and how stale the data is allowed to be.
2. Primary-Replica Replication
Solves: More read traffic than one database can serve.
The move: One machine accepts all writes and streams its change log to replicas that serve reads. If the primary dies, a replica is promoted.
The cost: Replicas lag behind the primary, so a user can write something and not see it on the next read. Replicas add zero write capacity, so this does nothing for a write bottleneck.
3. Sharding
Solves: Writes or data volume that have outgrown a single machine.
The move: Split the rows across machines by a shard key, so each machine owns one slice of the data.
The cost: The shard key decides everything. It should appear in nearly every query and spread load evenly. Get it wrong and you inherit cross-shard queries, cross-shard transactions, and hot keys.
4. Load Balancing
Solves: Distributing traffic across many identical servers without sending requests to unhealthy ones.
The move: A load balancer sits in front of the fleet, spreading requests according to health checks and current load.
The cost: Your servers have to be stateless first. Sessions, counters, and uploaded files must move out of the individual server, or each copy holds a different fraction of the truth.
5. Message Queue
Solves: Work arriving faster than you can process it, or a user waiting on work they should not have to wait for.
The move: Producers put work on a queue and workers consume it at their own pace. Traffic spikes become backlog instead of outages.
The cost: Delivery is at-least-once, so consumers must tolerate duplicates. Queue depth becomes a metric you have to watch, because a queue that only grows is an outage you have not noticed yet.
6. Publish-Subscribe
Solves: One event that several independent parts of the system need to react to.
The move: A publisher announces an event once. Any number of subscribers react without knowing about each other or about the publisher.
The cost: Your event schema becomes a public contract. Changing it turns into a negotiation with every team that consumes it.
7. API Gateway
Solves: Clients having to know about, and call, dozens of individual services.
The move: One entry point in front of the system handles routing, authentication, rate limiting, and response aggregation.
The cost: It becomes a single point of failure and a deployment bottleneck if too much logic accumulates in it. Keep it about cross-cutting concerns, not business rules.
8. Circuit Breaker
Solves: A slow or failing dependency taking your service down with it as threads pile up waiting.
The move: Track the failure rate. Past a threshold, stop calling the dependency and fail immediately. Probe occasionally to see whether it has recovered.
The cost: You have to decide what happens while the circuit is open. Returning an error is often the wrong answer, so pair it with cached data or a sensible default.
9. Idempotency
Solves: A retried request doing the same work twice, such as charging a customer for a second time.
The move: The client sends a unique key with each operation. The server records keys it has already processed and returns the original result instead of repeating the work.
The cost: You need somewhere to store those keys, and the retention window has to outlast the longest retry chain in your system.
10. CQRS
Solves: Reads and writes wanting different data shapes, where normalizing for correct writes makes reads slow.
The move: Keep a lean write model, and build separate read models shaped for the questions you actually ask, kept in sync from the write side's change stream.
The cost: Read models are eventually consistent, so a user may not immediately see their own write. Never sync the two by writing to both from application code, because dual writes drift silently.
Patterns vs Architectural Styles
Lists of "common system design patterns" often mix in layered architecture, client-server, peer-to-peer, and microservices. Those are architectural styles: they describe how you divide an application as a whole, and you generally pick one. The ten above are building blocks you apply inside whichever style you chose, and you use many of them at once.
Both matter, and they answer different questions. For the styles, see top 10 software architecture patterns. For the code-level Gang of Four patterns like Singleton and Observer, which are a third and separate thing, see the top must-know software design patterns.
How These Patterns Compose
Real systems combine them, and the seams are where the engineering happens. Retries demand idempotency. Caches demand a plan for when a popular key expires and a thousand requests miss at once. Queues demand a dead letter queue so one poisonous message cannot block everything behind it.
A news feed, for example, uses caching, sharding, message queues, publish-subscribe, and idempotency together, plus graceful degradation for when parts of it fail. No single pattern makes a system. The combination does.
Frequently Asked Questions
How many system design patterns are there? Around sixty cover essentially everything used in production and asked in interviews, spanning communication, storage, caching, reliability, scaling, consistency, APIs, operations, data processing, and AI infrastructure. The ten above are the ones you meet first and most often.
Which ones matter most for interviews? Cache-aside, sharding, message queues, circuit breakers, idempotency, sagas, CQRS, and rate limiting appear in the large majority of system design rounds. Learn those deeply before broadening.
Are system design patterns the same as design patterns? No. Design patterns from the Gang of Four book organize code inside one program. System design patterns organize infrastructure across many machines. In a system design interview, the interviewer means the second kind.
Next Steps
These ten are the starting set. For all sixty-plus patterns organized by category, with the cost and the "when not to use it" for each, see the complete guide to system design patterns.
If you would rather work through them in order, you can study system design patterns one production incident at a time in my course on them.
GET YOUR FREE
Coding Questions Catalog
$123
$197
$72
