Blog

One service that sends push, email and SMS for every other team: an API by notification type, user preferences and quiet hours, deduplication, per-channel queues, retries with a dead-letter queue, provider failover, digests and batching, and delivery tracking.

The classic first system design question, worked end to end: requirements, the numbers, key generation, the data model, the redirect path, caching, analytics, and what breaks first. With the trade-offs an interviewer will push on.

How 'drivers near me' and 'restaurants within 2 km' work at scale. Geohashes turn a latitude and longitude into a string whose prefixes are map cells, quadtrees split space where the data is dense, and both turn a 2-D search into a few 1-D lookups.

An overloaded server that accepts everything ends up serving nothing: queues grow, every request times out, and retries make it worse. How bounded queues and concurrency limits turn overload into fast rejections, how to shed the least important work first, and how to degrade features instead of failing whole pages.

You save a change, the page reloads, and your change is gone — then it reappears. Asynchronous replicas lag behind the primary, and reads routed to them break guarantees users take for granted. The consistency guarantees that matter (read-your-writes, monotonic reads, consistent prefix) and how to provide each one.

Why auto-increment stops working once you shard, what UUIDv4 costs you in index performance, and how Snowflake-style IDs and UUIDv7 pack a timestamp, a machine number and a counter into a sortable 64- or 128-bit ID without any coordination.

A committed transaction must survive a power cut, but writing every changed page to disk on commit would be far too slow. The write-ahead log solves both: append a description of the change, flush it, and replay it after a crash. How it works, checkpoints, fsync, and how the same log powers replication.

How to turn 'a hundred million users' into requests per second, storage, bandwidth and cache size in a few lines of arithmetic. The handful of numbers worth memorising, a worked URL-shortener example, and how each estimate should change the design.

When one business operation spans several databases, there's no single transaction to wrap it in. How two-phase commit makes it atomic at the price of blocking, how sagas use compensating actions instead, orchestration vs. choreography, and the isolation problems sagas leave you to solve.

Instead of overwriting the current state, store every change as an immutable event and derive state by replaying them. What event sourcing gives you — full history, audit, time travel, new views of old data — what it costs, and how CQRS fits alongside it.