System Design & Architecture Interview Questions

About these system design questions

System design interviews ask you to build something large on a whiteboard, but the conversation is mostly about trade-offs: what happens when a node fails, when one customer sends far more traffic than the rest, or when a retry arrives twice. A whole design session is hard to practise alone. The decisions inside it are not, and each question here isolates one of those decisions in a short scenario with a clear right answer.

They are aimed at backend, platform and SRE candidates at mid and senior level, and at anyone moving into architecture work. The ideas are vendor-neutral, but they are also what the cloud architect certifications test once you strip away the service names. A question about asynchronous replication or retry storms here is the same question as a multi-Region or decoupling scenario on an AWS, Azure or Google Cloud architect exam.

What the questions cover

• CAP and consistency models. Choosing consistency over availability during a partition when double-selling is unacceptable, and giving users read-your-writes consistency without making every read go to the leader.
• Caching. What happens when a hot, expensive cache key expires under heavy load, and how to stop thousands of requests rebuilding it at once.
• Load balancing. When routing needs a layer 7 load balancer that reads the URL path, rather than a layer 4 one that only sees connections.
• Sharding and partitioning. Why adding shards doesn't help when one tenant's key sends all its traffic to a single shard, and how to split a hot key.
• Replication. What asynchronous replication can lose during a failover, and what it costs to make acknowledged writes durable.
• Rate limiting and back-pressure. Why a fixed-window counter lets a burst through at the window edge, and how a token bucket smooths it.
• Retries and idempotency. Exponential backoff with jitter so clients don't retry in lockstep, and idempotent consumers for queues that deliver at least once.
• Scalability. Moving session state out of the server so a tier can scale out instead of up.

How to use them

There is one practice test of 10 questions, from easy to hard. Each explanation covers why the right design fits and why each alternative breaks one of the stated requirements, with links to sources such as the Azure Architecture Center patterns, the Amazon Builders' Library and the Google SRE book.

• Read the constraints before the options. Each scenario has one requirement that rules out the tempting answer, such as "never sold twice", "same hostname" or "the database has headroom".
• After each question, say the trade-off in one sentence: what the chosen design gives up. That sentence is what interviewers listen for.
• Read the pattern pages behind the explanations, such as Retry, Rate Limiting, Sharding, Cache-Aside and Idempotent Consumer. Each is short and names the problem it solves.
• Then practise full designs out loud, and notice where these smaller decisions come up. They almost always do.

These questions are original, written from public architecture guidance and engineering writing. They are not taken from any real interview or exam.