System Design Cheat Sheet for Senior Engineer Interviews

NoSQL Databases (Non-Relational)

NoSQL databases are more flexible. They do not require a fixed schema. You can store different kinds of data in the same collection without everything following the same structure.

There are several types. Document stores (like MongoDB) save data as JSON-like objects. Key-value stores (like Redis) are extremely fast and map a key to a value. Wide-column stores (like Cassandra) are designed for massive amounts of data spread across many machines.

NoSQL databases scale horizontally more easily.

The trade-off is that they often sacrifice some consistency guarantees to achieve that scale.

How to Choose

If your data is structured and relationships matter, lean toward SQL.

If you need flexibility, speed, or horizontal scalability, lean toward NoSQL.

In an interview, always explain your reasoning.

Learn more about SQL vs NoSQL.

Caching

A cache is a fast, temporary storage layer that sits between your application and your database. Its whole purpose is to avoid doing the same expensive work twice.

Here is what happens without caching. Every time a user requests the same data, your server goes to the database and runs the query.

If a thousand users request the same thing, that is a thousand identical database queries. Wasteful.

With a cache, the first request goes to the database. The result gets stored in the cache.

The next 999 requests get their answer from the cache, which is dramatically faster because it stores data in memory.

Redis and Memcached are two popular caching tools. They store data in memory, making reads extremely fast.

Cache Invalidation

The hardest part about caching is knowing when your cached data is outdated. This is called cache invalidation.

Write-through cache updates the cache every time the database is updated. Data is always fresh, but writes are slower.

Write-back cache writes to the cache first and updates the database later. Faster writes, but you risk losing data if the cache crashes.

TTL (Time to Live) gives each cached item an expiration time. After that time passes, the item is removed and the next request fetches fresh data.

In interviews, mentioning cache invalidation shows you understand caching is not a free lunch.

Content Delivery Networks (CDNs)

A CDN is a network of servers spread across different geographic locations.

When a user requests a static file (an image, a video, a CSS file), the CDN serves it from the server closest to that user.

Why does this matter? Because physical distance affects speed.

If your server is in New York and your user is in Tokyo, every request has to travel across the Pacific Ocean and back.

A CDN puts a copy of your static content near the user, making the response much faster.

In an interview, if the system involves serving media or static assets to a global audience, mentioning a CDN shows you are thinking about latency and user experience.

Message Queues

Not everything in a system needs to happen immediately. That is where message queues come in.

A message queue sits between two parts of your system.

One part (the producer) adds tasks to the queue.

Another part (the consumer) picks up tasks and processes them.

Why is this useful?

It decouples your components.

The producer does not need to wait for the consumer to finish. It drops the task in the queue and moves on. This makes your system faster for the user and more resilient.

If the consumer goes down temporarily, the tasks pile up in the queue and get processed when it comes back.

Popular tools: RabbitMQ, Apache Kafka, Amazon SQS.

In system design interviews, message queues are the answer whenever you need asynchronous processing, like sending emails, generating reports, or processing uploads.

Database Sharding and Replication

When a single database cannot handle the load, you have two main strategies.

Replication

Replication means creating copies of your database. You have one primary database that handles writes and one or more replicas that handle reads.

Since most applications read data far more often than they write, this takes a huge load off your primary database.

The trade-off is replication lag, a small delay between when data is written to the primary and when it appears on the replicas.

Sharding

Sharding means splitting your data across multiple databases. Each shard holds a portion of the total data.

This allows your system to handle far more data because no single database carries the full load. But sharding adds complexity. Cross-shard queries become difficult.

And picking the right shard key (the rule that decides which data goes where) is critical.

A bad shard key leads to uneven distribution.

In interviews, bring up sharding when the data volume is clearly too large for one database. But also mention the downsides.

Consistent Hashing

When you distribute data across multiple servers, you need a way to decide which server holds what.

Simple hashing (key modulo number of servers) works until you add or remove a server. When that happens, almost all the data needs to be remapped.

Consistent hashing solves this. It arranges servers on a virtual ring.

When you need to find where data lives, you hash the key and walk clockwise around the ring until you hit a server.

When you add or remove a server, only a small fraction of the data needs to move, not everything. This concept shows up frequently in interview questions about distributed systems.

Rate Limiting and API Design

When you design a system that exposes an API, you need to protect it from being overwhelmed.

Rate limiting controls how many requests a user or client can make within a given time window.

Without rate limiting, a single user or a malicious bot could flood your system with requests and take it down for everyone. The most common algorithm is the token bucket. It gives each user a bucket that fills with tokens at a steady rate. Each request costs one token. When the bucket is empty, requests are rejected until more tokens accumulate.

Mentioning rate limiting in an interview signals that you think about system reliability and abuse prevention.

Learn about the most crucial aspects of system design interview.

Putting It All Together

System design is not about knowing every tool. It is about understanding what problems exist and which tools solve them.

When you walk into an interview, you are not expected to build a perfect system on a whiteboard. You are expected to think clearly, communicate your reasoning, and show that you understand trade-offs.

Every concept in this post connects to a real problem:

• Too much traffic for one server? Horizontal scaling and load balancers.

• Slow database reads? Add a cache.

• Database overloaded? Replication for reads, sharding for data volume.

• Global users experience lag? Use a CDN.

• Tasks that do not need to be instant? Message queue.

• Distributing data across servers? Consistent hashing.

• System getting abused? Rate limiting.

For a complete prep guide, check out Grokking the System Design Interview course by DesignGurus.io.

Key Takeaways

• Always start with a framework. Clarify requirements, estimate scale, sketch the architecture, then deep dive.

• Horizontal scaling is the default for large-scale systems. Vertical scaling has a hard ceiling.

• Choose your database intentionally. SQL for structured, relational data. NoSQL for flexibility and scale.

• Caching speeds things up but introduces cache invalidation challenges. Know the strategies.

• Message queues decouple components and enable asynchronous processing for non-urgent tasks.

• Sharding and replication are how databases scale, but they come with complexity.

• Trade-offs matter more than perfect answers. Interviewers want to see critical thinking about design decisions.