System Design interview questions

Complete the two key concepts: A load balancer balances incoming network traffic across multiple servers to improve availability and throughput. When user session data must remain on the same server for the duration of a session, this is called sticky persistence.

The Circuit Breaker pattern is the most appropriate choice. It tracks failure rates to Service B and, once a threshold is exceeded, 'opens' the circuit so subsequent calls fail fast instead of blocking. This prevents Service A's thread pools from being exhausted waiting for a slow or unreachable dependency, allowing the system to degrade gracefully rather than cascade-fail.

This is false. A core microservices principle is that each service should own its own dedicated database ('Database per Service' pattern). Sharing a centralized database tightly couples services together — schema changes in one can break others, it creates a single point of failure, and it defeats independent deployability. Cross-service data consistency is handled through eventual consistency and patterns like Sagas.

The correct order is: Load Balancer / Ingress → API Gateway → Service Registry lookup → Target Microservice. In client-side service discovery (e.g., Netflix Eureka + Ribbon), the API Gateway itself queries the Service Registry to find a healthy instance before forwarding the request, making the registry lookup a distinct step that occurs after the gateway and before the microservice.

In cache-aside the application code owns the cache: on a read it checks the cache first, and on a miss it loads from the database, populates the cache, and returns. Writes go to the database and then invalidate (or update) the cache entry. Its main failure mode is the thundering herd / cache stampede — when a hot key expires, many concurrent requests all miss and hammer the database at once. Mitigate with request coalescing (single-flight), a short lock per key, or probabilistic early refresh.

Vector clocks (or version vectors) with application-level or CRDT-based merging are the best fit. They capture causal relationships between writes across regions, allowing the system to detect true conflicts (concurrent writes with no causal ordering) and apply deterministic merge logic — without requiring cross-region coordination on the write path. LWW risks silent data loss due to clock skew, 2PC sacrifices availability, and read repair only acts on the read path.

The correct statements are (b), (c), and (d). A message queue like Kafka decouples producers and consumers and smooths traffic spikes. Stateful services require externalised or sharded state before horizontal scaling; just adding instances risks split-brain. Read replicas offload read traffic from the primary. Option (a) is wrong because CDNs cache HTTP responses at the edge — they cannot introspect or cache arbitrary database query results.

A message that always throws (a 'poison pill') is requeued endlessly with no attempt limit, so it loops forever at the head of the queue and starves every other message; it needs a redelivery counter that routes to a dead-letter queue after N attempts

Requirements. Two operations dominate: create (write a mapping, optionally with a custom alias and expiry) and redirect (look up a code and 30x to the long URL). The system is overwhelmingly read-heavy (100:1), so the redirect path is what we optimise. I'd confirm: are custom aliases required (yes), do links expire (optional TTL), and how precise must click counts be (approximate/eventually-consistent is fine). I'd use a 302 (temporary) redirect so we keep serving redirects through our system and can still count clicks; a 301 would let browsers cache and bypass us.

Capacity. ~40 writes/sec average, ~200/sec peak; ~4K reads/sec average, ~20K peak. Storage: ~6B links over 5 years; at ~500 bytes/row (code, URL, metadata) that's ~3 TB — comfortably shardable. Keyspace: base62 with 7 characters gives 62⁷ ≈ 3.5×10¹² codes, far more than 6B, so 7 chars (often padded to a fixed length) is plenty. The hot working set (recently/ popularly accessed links) is a small fraction of 6B, so a cache of tens of GB covers the bulk of redirect traffic.

Data model. A single mapping table/collection keyed by the short code: code (PK) → long_url, created_at, expires_at, owner_id. Point lookups by primary key suit a key-value store (DynamoDB/Redis-backed) or a sharded relational table sharded by code. Click counts live separately — incrementing a counter on every redirect would put write load on the read path — so clicks are emitted as events and aggregated asynchronously.

Short-code generation. Generate a unique 64-bit id (a distributed counter handed out in ranges per server, or a Snowflake-style id) and base62-encode it to get the short code; this guarantees uniqueness with no collision checks and no hotspot from a single shared counter. Custom aliases are written directly with a uniqueness check and stored in the same table, reserving that code. (A hash-of-URL scheme is the alternative but needs collision handling and breaks idempotency for duplicate URLs.)

Read/write paths. Write: allocate id → base62 → insert mapping → return the short URL. Redirect: a load balancer / CDN fronts stateless app servers; the server does a cache-aside lookup (code → long_url) in Redis, falling back to the store on a miss and populating the cache, then returns a 302. This keeps p99 well under 100 ms for cache hits. Expiry is enforced by TTL on both the row and the cache entry. Each redirect fires a lightweight click event onto a queue (Kafka) that a consumer aggregates into per-link counts.

Bottleneck & scaling. The bottleneck is the redirect read path at peak. We scale it with cache layers (most reads never touch the store), read replicas, and sharding the mapping store by code so lookups stay single-shard. Id generation scales by handing each server an independent id range (or using Snowflake), avoiding a single global counter as a SPOF. At 10× traffic, the cache absorbs most of it; we add cache nodes and replicas and, if needed, push redirects further to the edge.

1. This is the hot shard (or write-hotspot) anti-pattern. Because event_id is monotonically increasing, new events always map to the uppermost range, which belongs to the last (highest-range) shard. All other shards only receive reads for historical data, never new writes. The range boundaries do not self-adjust, so the system is effectively single-shard for writes.

2. Consistent hashing maps both shard nodes and keys onto a circular hash ring. Each key is owned by the first node clockwise from the key's position on the ring. When a node is added or removed, only the keys between the new node and its predecessor (approximately K/n keys, where K is total keys and n is node count) need to be remapped and migrated. All other keys remain on their current nodes. This minimal disruption property — O(K/n) remapping vs O(K) for naive modular hashing — makes it operationally far superior for elastic, dynamically scaled shard clusters.