#postgres

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

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?

A green tick appears before you've stopped typing, and behind it is a list of a billion taken names. It isn't one clever database query.

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.

Two requests read the same row, both do their maths, both write back. One of them silently disappears. How the system should resolve that isn't one answer: it depends on whether the write is a delta, a quick piece of logic, or a human edit made minutes after the read.

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.

Give each tenant its own schema and you get real isolation. You also get two new problems: knowing where each tenant lives, and running one migration correctly five hundred times instead of once.

One app, many customers, one WHERE clause keeping them apart. Forget it once and nothing crashes: tenant A just sees tenant B's invoices. How to make isolation something the system enforces, not something engineers remember.

You tap your card, the machine freezes, you tap again. Were you charged twice? An HTTP payment endpoint faces the same question on every retry, and without an idempotency key it gets it wrong.

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.

An endpoint that queries once per parent row instead of once per request looks fine with ten rows and falls over with ten thousand. Batch the per-row lookups into one query and the round trips disappear.

A client that retries a POST after a timeout can create the resource twice or charge a card twice. An idempotency key lets the server spot the retry and replay the first response instead of doing the work again.