Tags

On 2 July 2019 a single new firewall rule took Cloudflare, and a large part of the web with it, offline for 27 minutes. Not an attack, not a hardware failure. How does one rule do that to every server at once?

Pay by bank looks like two taps in the pitch deck. In production it's five hand-offs across three companies, and every one of them loses people.

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

"What happens between typing a URL and seeing the page?" I've shipped web apps for years, and in an interview I still fumbled it.

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.

Closing every ticket on a feature doesn't mean the feature works. So whose job is it to find out?

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?

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.

Two eggs, a 100-floor building, and the fewest drops that are guaranteed to find the floor where eggs start breaking. Binary search is the obvious answer, and it loses badly.

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.

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.

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.

A team rewriting its app in this month's framework to fix the speed, a search box whose effects set state that sets more state, and a marketing page that ships more JavaScript than a video game. None of them is fixed by switching tools.

A standup where everyone recites yesterday to the manager, forty minutes arguing 3 versus 5, and a retro whose actions nobody picks up.

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.

Six rounds, a weekend take-home, and a hard LeetCode problem, all to hire someone who'll spend their first quarter adding fields to a form. Most interview loops test whether you can pass interview loops, and I'd rather test the job.

One camp says AI is about to replace engineers. The other ships two hundred generated lines, with tests generated from the same code, on the strength of a Friday LGTM. Both treat the model as the one doing the job, but the model never pressed merge.

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.