Backend System Design

Concept Questions

Short verbal drills. Answer in 60–90 seconds each — definitions, when to use, and one trade-off.

1. How to use this page

Cover the question, speak your answer, then check the bullet points. These are the “concept” questions interviewers ask before or during a design.

Vertical: bigger machine (CPU/RAM). Simple, hard ceiling, SPOF risk.
Horizontal: more machines. Needs stateless apps, partitioning, more ops complexity.

When you have more than one app instance and need to distribute traffic, health-check, and fail over.

No user session stored in process memory. Session/cart lives in Redis/DB so any instance can serve the request.

App checks cache → miss → read DB → populate cache → return. On write: update DB, invalidate (or update) cache.

Hot key expires; many requests miss together and hammer DB. Fix: single-flight, soft TTL, mutex, stale-while-revalidate.

In a partition, you choose consistency or availability; you cannot have both perfectly with partition tolerance.

N replicas, W write ACKs, R read responses. If R+W>N, read and write sets overlap in the stable case → stronger read-after-write. Lower W/R for latency/availability.

Follower is behind the leader. Read-your-writes can break if you read from a lagging replica.

SQL: relations, transactions, complex queries. NoSQL: flexible schema, massive horizontal scale, simpler access patterns.

Probabilistic set: “definitely not present” or “maybe present.” Tiny memory; used to skip disk/SSTable reads or block cache penetration. False positives OK; false negatives are not.

If a replica is down, another node temporarily accepts the write and later forwards the hint when the replica recovers. Boosts availability; pair with read repair / anti-entropy.

When nodes join/leave, only neighboring keys move — not a full hash % N reshuffle. Add virtual nodes for balance. Used in caches, KV rings, some LBs.

Static or cacheable content for global users: images, JS, video segments, downloads. Cuts origin bandwidth and latency. Need Cache-Control + purge/versioning for updates.

Async work, absorb bursts, decouple producers/consumers, retry failed work. Avoid for hard sync latency (< few hundred ms).

Doing the same operation twice has the same effect as once. Use idempotency keys on payments/creates; consumers dedupe by message id. Required whenever retries exist.

At-least-once: broker/client may redeliver → duplicates possible → make handlers idempotent (most common practical answer).
At-most-once: no redelivery → can lose messages; rare for critical work.
Exactly-once: end-to-end once effect. Hard; often “effectively once” via idempotent writes + transactional outbox / Kafka EOS in a limited scope. Do not claim magic exactly-once across arbitrary side effects (email, SMS) without a dedupe store.

Stop calling a failing dependency; fail fast; probe later in half-open state to avoid cascading failure.