What "one box" means when you say it honestly
Saying "one PostgreSQL box" in a design round invites the obvious reply: so it is a single point of failure. Pre-empt it by describing what you mean. One primary takes every write. A streaming replica in another availability zone can be promoted if the primary dies. WAL archiving gives point-in-time recovery, and someone has actually restored from it. A connection pooler sits in front, because the application tier will scale out faster than the database's connection limit.
That is one writer, not one machine. It removes the hard parts of distribution, such as cross-node transactions, consensus and reconciling replicas that disagree. It keeps redundancy. Candidates who say "one box" and mean a single unreplicated server have given the interviewer a real reason to mark them down.
Do the capacity estimate out loud
The answer is only as strong as the arithmetic behind it, and every number must trace back to something stated. Suppose the prompt describes a booking system with 2 million daily active users, and you assume each makes 10 writes a day.
writes/day = 2,000,000 users x 10 = 20,000,000
average writes = 20,000,000 / 86,400 s ~ 230 per second
peak writes = 230 x 10 (assumed peak factor) ~ 2,300 per second
row + indexes = 1 KB per write (assumed)
growth = 20,000,000 x 1 KB ~ 20 GB per day, ~7.3 TB per year
Now compare that peak with a ceiling, and be explicit about where the ceiling comes from. If you have run PostgreSQL at this write shape, say what you measured. If not, state an assumed ceiling as an assumption and invite correction: "I am assuming a well-provisioned primary handles a few thousand simple indexed writes a second; if your number is lower, the conclusion moves." An interviewer will accept a stated assumption they can argue with. A confident benchmark you cannot source is the thing they will probe.
Reads mostly do not bound the design, because replicas and caches absorb them. What one primary does bound is write rate and dataset size.
The estimate usually shows that throughput is not what breaks first. Look at growth instead. At 7.3 TB a year, assume restores run at 500 MB a second: 7.3 TB divided by 500 MB/s is about 14,600 seconds, roughly four hours. If the business's recovery time objective is one hour, the single box has hit a limit at a few hundred writes a second. That limit has nothing to do with throughput, and you only find it by doing the sums. Failover covers a dead machine; a restore is what covers a bad migration or a dropped table, so it is the path to measure. Retention, table partitioning by time and archiving old data are the first responses, and none of them is a distributed database.
When it is the strongest answer in the room
It wins when three things line up. The estimate fits with headroom, by a factor you can name, say tenfold. The domain has invariants that cross entities: money that must balance, inventory that cannot go negative, a room that cannot be double-booked. And the team or product is young, so the cost of running distributed infrastructure buys nothing yet.
The invariant argument is the one that lands hardest, because you can show it. In one database, "no overlapping bookings for the same room" is a constraint the engine enforces on every insert:
CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE TABLE booking (
room_id bigint NOT NULL,
during tstzrange NOT NULL,
EXCLUDE USING gist (room_id WITH =, during WITH &&)
);
Partition that table across nodes and the guarantee survives only if both bookings for a room always land on the same node. Otherwise you are building distributed locking or a reservation protocol to recover something PostgreSQL gave you in one statement. Weighing that cost honestly is what senior judgement looks like.
When it ends the interview
The first way is the prompt ruling it out and you not noticing. If users in London and Sydney must both keep writing while either region is down, a single primary cannot meet the requirement. Physics settles it before architecture does. Light in fibre covers roughly 200,000 km a second, and London to Sydney is about 17,000 km along the great circle. That puts one round trip at around 170 ms or more, before any routing, for every write from the far side. And a region outage stops writes until failover completes. Insisting on one box there is not simplicity; it is failing a requirement.
The second way is subtler and more common. The interviewer asked a distributed-systems question because they want to see you reason about partitioning, replication and failure. "I would just use Postgres", said as a full stop, may be correct for the toy numbers in the prompt and still give them nothing to score. You have answered a question they did not ask and declined the one they did.
Say the box, then earn the distributed design
The strong move is not choosing between being right and playing along. State the single box, with numbers. Name the specific signal that would retire it: peak writes approaching the measured ceiling, restore time exceeding the recovery objective, a requirement for writes in two regions. Then ask whether they want the design for the scale where it breaks, and build that version properly.
That next version should keep the reasoning that made the first one good. Choose the partition key so the core invariant stays inside one partition. Sharding the booking system by tenant or venue keeps every room's bookings together, so the exclusion constraint still holds within each shard. Sharding by user scatters a room's bookings across shards and silently loses it. Then say what got harder: cross-shard reports, rebalancing when one tenant outgrows its shard, and schema migrations run many times instead of once.
An interviewer comes away from that with two signals they could not get otherwise. You will not build distribution you do not need, and you know exactly what it costs when you do.
One Postgres primary is a design, not an evasion, when the estimate fits and the invariants need transactions. Show the arithmetic, name the limit that would end it, and then design past that limit. Stopping at "just use Postgres" answers a question nobody asked.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).