User opens the app. Show the nearest 10 coffee shops. Sounds simple until you realize ’nearest’ means computing distance against millions of locations in under 100ms.

Manhattan has 50,000 restaurants. Rural Wyoming has 3 per county. A fixed-size grid wastes cells on empty space and overloads dense areas. Quadtrees adapt.

Your user is at latitude 37.7749, longitude -122.4194. Your database has 10 million locations. A full table scan comparing every coordinate pair isn’t going to work.

You split work evenly across 4 threads. Two finish in 10ms, two take 10 seconds. Half your CPU sits idle while the other half grinds. Work stealing fixes this.

Send a reminder in 24 hours. Retry this job in 5 minutes. Expire this hold at midnight. Delayed execution is everywhere, and Thread.sleep isn’t the answer.

Three nodes, one job. Without leader election, all three run it simultaneously. With leader election, exactly one does the work while the others stand by.

Your dataset is 10TB. One machine can’t hold it, let alone process it. MapReduce splits the work across hundreds of machines with a deceptively simple API.

A normal index maps documents to words. An inverted index maps words to documents. That reversal is why search is fast.

A batch job runs for three hours and crashes at hour two. Without checkpointing, you restart from zero. With it, you lose ten minutes of work.

Exact duplicates are easy. Near-duplicates are hard. SimHash turns documents into compact fingerprints where similar content produces similar hashes.

FIFO queues treat every message equally. But urgent config updates shouldn’t wait behind a thousand bulk sync jobs. Priority queues fix this, if you handle starvation.

Your database says one thing. The external system says another. Reconciliation is how you find the drift before your users do.

Boolean flags and status strings create impossible states. An explicit state machine tells you exactly where a workflow is, what transitions are valid, and how to recover.

Two users update the same row. Pessimistic locking blocks one until the other finishes. Optimistic locking lets both try and fails the loser. Choosing wrong kills either throughput or correctness.

Two-phase commit guarantees atomicity across multiple databases. It also blocks everything if the coordinator dies. Here’s why microservices moved on.

Every public write endpoint is an abuse vector. Layered defense with validation, rate limiting, and async scanning keeps your system safe without killing performance.

Counting unique items across billions of events. A HashSet needs gigabytes. HyperLogLog does it in 12KB. The trick is accepting a little error.

100% availability is impossible and pursuing it wastes engineering time. SLOs turn reliability into a number you can reason about.

Auto-increment IDs break the moment you have more than one database. Snowflake IDs, UUIDs, and database sequences each solve this differently.

Showing every individual event overwhelms users. Grouping related events into summaries is a distributed systems problem hiding as a UX problem.

Green dot means online. Simple, right? Behind that dot is a distributed system making heartbeat-based guesses about user liveness.

User posts an update. Do you push it to all followers immediately, or let them pull it when they check? The trade-off shapes your entire architecture.

Your client needs real-time updates from the server. HTTP wasn’t built for this. Here’s how long polling, SSE, and WebSockets solve it differently.

Cache expires. 10,000 requests hit the database simultaneously. Your DB collapses. How request coalescing and probabilistic expiration prevent the stampede.

Grep through 50 log files to find one request. Or use structured logging with correlation IDs and find it in seconds.

Your average latency looks great. Your P99 is a disaster. Why tail latency matters more than averages, and what you can actually do about it.

Events arrive out of order. User updates overwrite each other. Here’s how partition keys, sequence numbers, and causal ordering keep things straight.

Your consumer retried a bad message 10,000 times. It will never succeed. Dead letter queues catch the messages that can’t be processed so the rest of your system keeps moving.

Exactly-once delivery is impossible across boundaries. Here’s the pattern that actually works: at-least-once delivery with idempotent consumers.

Kafka says exactly-once. Your consumer processed the message twice anyway. Here’s why exactly-once is impossible across system boundaries.