#distributed-systems

Your ledger says a payment succeeded. The provider's settlement report, days later, disagrees. Which one is right?

Every service is healthy and the dashboard average looks great, yet support is full of customers saying the app is slow. Both are telling the truth.

Counting unique visitors sounds like a set: add every user id, read its size. At a few billion ids that set is tens of gigabytes, kept only to produce one number. Do you need to remember who visited to count them?

A celebrity posts and a million people tap the heart in ten minutes, and every one of them sees a count that seems to keep up. One row with a number in it can't take that. So what does?

Save to the database, then publish an event: two lines, two systems, and nothing that makes them agree. What happens when the process dies in between, and why every obvious fix still leaves a gap.

A checkout handler that calls the ledger, the warehouse, the email service and analytics in a row is as slow as all of them added together and as fragile as all of them multiplied. And every team that cares about payments makes it a little worse.

Your checkout logs a line at every step, which looks like good observability. Then a customer says their payment failed, and you find out what those logs can't tell you.

One product-page endpoint, the same code, ten times more traffic, then ten times more again. Each step breaks something different, and the last one breaks something extra capacity can't fix.

The interviewer asks how much traffic you're expecting. Round to powers of ten, turn per-day into per-second, and end every number on the design decision it forces: one node, a cache, or a shard.