Intermediate System Design Interview Questions

When the network between nodes fails, a distributed store must choose between consistency (refusing some requests) and availability (answering, possibly with stale data). Partitions cannot be avoided, so that is the real choice.

Copies may differ for a while, but they eventually agree. It suits likes, feeds and view counts, but not bank balances.

In cache-aside, the app fills the cache on a miss. In write-through, writes go to the cache and database together. In write-back, writes go to the cache first, and later to the database, which is fast but risks data loss.

A popular entry expires, and many requests hit the database at once. Use a lock so that one request refills it, serve stale data while refreshing, and add randomness to TTLs.

Delete the entry on write, and use a TTL as a safety net. For stronger guarantees, use change data capture to invalidate entries.

Replicas fall behind the primary. To handle it, read a user's own recent writes from the primary, and use sticky reads, so that time never goes backwards for a user.

It should have many values, spread load evenly, and match your main queries, so that most queries touch one shard. Avoid time-based keys, which send all new writes to one shard.

Servers and keys are placed on a ring, and a key belongs to the next server clockwise. Adding a server moves only a small share of keys. Virtual nodes even out the load.

Reads scale with caches and replicas. Writes scale with sharding, queues and batching, since every replica must apply every write.

Repeating an operation has the same effect as doing it once. Networks cause retries, so payments and other writes need idempotency keys, to avoid duplicates.

At-most-once may lose messages, at-least-once may repeat them, and exactly-once is hard. Most systems use at-least-once, with idempotent consumers.

Kafka is a replayable log for high-volume event streams. RabbitMQ is a broker, good for task queues and flexible routing.

Use a token bucket or sliding window, stored in Redis with atomic operations, enforced at the gateway, keyed by user or API key, and returning 429 with Retry-After.

Offset allows jumping to a page, but it slows on deep pages and can repeat items. Cursors stay fast and stable, so they suit feeds.

WebSockets suit two-way, real-time apps such as chat. Server-sent events suit one-way updates. Polling is simplest, and suits infrequent changes.

Make the check and update atomic, with row locks or a conditional UPDATE, and add a unique constraint. Use temporary holds during payment.

After repeated failures, calls to a service stop for a while, and fail fast. Trial requests then test recovery. This stops one failing service from dragging down others.

An SLI is what you measure, an SLO is your target, and an SLA is a promise to customers, often with penalties.

Averages hide slow requests. p95 and p99 show what your unluckiest users experience.

Fan-out on write prepares feeds in advance, so reads are fast, but posting is costly. Fan-out on read is the opposite. Many systems use a hybrid for accounts with many followers.