Walk me through an architectural decision in your current system that you would make differently at ten times the scale. What evidence would tell you that the moment has arrived?

What the interviewer is testing

Not whether you know how to scale things. Whether your current design contains a decision you have consciously deferred, and whether you know its trigger. Engineers who have only ever built for the scale they have answer this abstractly. Engineers who have operated something answer it with a specific component, a specific number and a specific signal they watch.

The second half of the question does most of the work. Anyone can say "we would shard". Far fewer can say what measurement would make them start, and why that measurement rather than another.

The clarifying questions worth asking

• Ten times the traffic, the data, the tenants, or the team? These break different things. Traffic usually breaks the serving path; data breaks the storage layout and the backup window; tenants break isolation; team size breaks the boundaries, and that one is the least anticipated.
• Over what period? A 10× shift across three years is a roadmap; across three months it is an incident.

The arc of a strong answer

1. Name one decision, not a list. "We keep every tenant in one Postgres database with a tenant column."
2. Say why that was right. No cross-tenant routing layer, single backup, ordinary joins for analytics, one migration to run. A decision defended on its merits reads differently from one being apologised for.
3. Name what breaks first, mechanically. Usually not query latency — more often the maintenance window: the time to restore, to run a schema migration, or to vacuum. Availability of the operation, not the throughput of the workload.
4. Give the trigger with a number and a margin. "Restore time crossing four hours, because our RTO is six and I want two hours of margin." Or: "the largest tenant exceeding 20% of total rows, because that is the point where noisy-neighbour isolation stops being a policy question."
5. Say what you did to keep the option open — a tenant ID on every row, no cross-tenant foreign keys, the data-access layer already routing through one function. Cheap now, and it is what makes the later change a migration rather than a rewrite.

Common weak answers

• "We would move to microservices." A non-answer: it names an architecture, not a constraint, and does not say what breaks.
• "We built it to scale from day one." Invites the follow-up about what that cost, and the honest answer is usually complexity that has not paid for itself yet.
• A trigger with no number. "When it becomes a problem" means the decision will be made during an incident.

What a strong answer adds

The reverse case: what you would remove at one tenth the scale. Someone who can name the machinery their system does not need yet has actually thought about the trade, rather than memorised one direction of it.