Free lesson · AWS for System Design Interviews

What an interviewer hears when you say "I'd just use Aurora"

Easy9 min readawssystem-designinterview-preparation

The Word Doing The Damage Is "Just"

"I'd just use Aurora."

"Just" signals that no decision was made. It frames the choice as obvious, which means either it genuinely was - in which case say why, briefly - or it was not considered.

An interviewer cannot tell which, and that is the whole problem.

Important: Every answer arrives with a set of possible explanations, and you are scored against the distribution rather than the best case.

"I'd just use Aurora" is consistent with three candidates:

The expert compressing. They have run Aurora at scale, know exactly why it fits, and are being efficient. Rare, and indistinguishable from the outside.

The competent chooser who did not narrate. They correctly identified that the workload is relational and picked a reasonable managed option. Fine - and the reasoning is invisible.

The defaulter. It is what their last team used. Most common.

The interviewer must now spend time distinguishing between them, and that time is subtracted from your interview. Worse, they are probing from a position of doubt rather than building on a position of confidence.

You do not get the benefit of the doubt in a hiring decision. Not from malice - because the interviewer has to write down a conclusion they can defend, and "they said Aurora and it was right" is not defensible evidence of depth.

What The Sentence Did Not Contain

Six things an interviewer needed and did not receive:

Missing	The question it leaves open
Why relational	What about the access patterns requires joins or transactions?
The alternatives	Was a key-value store considered and rejected? Why?
The access patterns	What queries does this system actually make?
The scale implication	Aurora has one writer. Does the write volume fit?
The failure behaviour	What happens during failover? Does the application handle it?
The cost shape	Always-on capacity. Is that right for this demand?

Every one of those is a follow-up the interviewer will now ask, and you will answer them under pressure, one at a time, in an order they chose.

Or you could have answered them in twenty seconds, in an order you chose.

The Twenty-Second Version

"The access patterns here include joins across users, orders, and inventory, and the checkout flow needs a transaction across three tables. That rules out a key-value store - I'd be reimplementing joins in application code. So relational: Aurora PostgreSQL, because the read scaling matters and failover is fast. The constraint I'm accepting is a single writer, so if write volume outgrows one instance I'd need to partition by tenant, and I'd choose the partition key now even though I'm running one shard."

Tip: That paragraph is roughly seventy words and it does five things the six-word version did not.

It states the requirement - joins and a cross-table transaction - which is the actual reason.

It names the rejected alternative and why, which proves a choice was made.

It names the accepted cost - one writer - which is the senior move. Volunteering the weakness of your own choice is the single strongest signal available in a system design interview.

It states the scaling path, so the interviewer knows you have thought past today.

It makes a design decision now - choosing the partition key early - which demonstrates you know which decisions are expensive to reverse.

The interviewer now has evidence they can write down, and the next several minutes go to the interesting parts of the design instead of to probing whether you understand your own choice.

The Underlying Rule

graph TD
    A[Your answer] --> Q{Could this have<br/>been produced<br/>**without understanding**?}
    Q -->|Yes| W[**Scored as though<br/>it was.**<br/>Interviewer must probe.]
    Q -->|No| S[**Strong signal.**<br/>Evidence they can<br/>write down.]
    W --> W1['I'd use DynamoDB'<br/>'It scales horizontally'<br/>'We'd add a cache'<br/>'Aurora handles that']
    S --> S1[Requirement stated<br/>Alternative rejected<br/>**Cost volunteered**<br/>Limit named]

This diagram shows the underlying rule for evaluating a system design answer. Ask whether the answer could have been produced without understanding. If yes, it is scored as though it was, and the interviewer must probe - examples include saying you would use DynamoDB, that something scales horizontally, that you would add a cache, or that Aurora handles it. If no, it is a strong signal and gives the interviewer evidence they can write down - examples include stating the requirement, naming the rejected alternative, volunteering the accepted cost, and naming the limit.

Important: Apply this test to every sentence: could someone who did not understand this have said it?

"It scales horizontally" - anyone could say that about anything. Scored as nothing.

"It scales horizontally because writes are partitioned by user ID, which distributes evenly since no single user generates disproportionate volume - unlike a design keyed on tenant, where one large customer would create a hot partition" - that could not have been said without understanding.

The second is not longer because it is padded. It is longer because it contains the reasoning, and the reasoning is the deliverable.

The Same Failure In Other Clothes

"Aurora" is the example. The pattern is much wider.

The compressed answer	What it hides
"We'd add a cache."	What is cached, what is the key, what is the TTL, what happens on a miss storm, what about invalidation
"It's eventually consistent, that's fine."	Fine for whom? Which reader tolerates staleness, and for how long?
"We'd shard the database."	On what key? What about cross-shard queries? How do you rebalance?
"Kafka handles that."	Ordering is per partition. What is your partition key?
"We'd make it multi-region."	Which write topology? What about conflicts? What does it cost?
"Lambda scales automatically."	To a concurrency limit. What happens at it?

Each of these is a place where a service or pattern name is substituting for a design decision - and each invites a follow-up you would rather have pre-empted.

Volunteering The Weakness

The behaviour that most separates senior candidates, and it is counterintuitive.

Naming the cost of your own choice, unprompted, before the interviewer finds it.

Tip: Candidates avoid this because it feels like admitting a flaw. It reads as the opposite.

An interviewer hearing "the constraint I'm accepting is a single writer" learns that you understand the option well enough to know its limits, that you made a trade rather than a default choice, and that you will not be surprised in production. All three are exactly what a hiring decision is trying to establish.

The alternative is that the interviewer finds the weakness themselves and asks about it - at which point you are defending rather than explaining, and the tone of the remaining conversation shifts.

The formula: "the trade-off I'm accepting is X, and if it becomes a problem the path is Y." Two clauses. Use it at every significant decision.

Compression Is Not Always Wrong

A caveat, because the advice can be over-applied.

Not every decision warrants seventy words. A design with fifteen components cannot afford full reasoning on each, and a candidate who narrates every trivial choice runs out of time before reaching the interesting parts - which is its own failure.

Important: Spend the reasoning where the decision is load-bearing, and compress everywhere else.

Load-bearing decisions - the data model, the partition key, the consistency choice, the sync-versus-async boundary, anything expensive to reverse. These get the full treatment.

Everything else - the load balancer, the DNS provider, the secrets store - can be a service name in passing. Nobody is assessing whether you chose an ALB thoughtfully.

The discriminator: would a different choice here change the system's properties? If yes, explain it. If not, name it and move on.

A candidate who explains their load balancer choice in depth and compresses their partition key strategy has inverted the priority, and that inversion is itself a signal about judgement.

Recovering When You Have Already Said It

You will do this. Everyone does, under time pressure.

Notice and expand, without apologising. "Let me back up on that - the reason relational fits is the transaction across three tables at checkout. A key-value store would mean implementing that in application code."

Do not apologise for it. "Sorry, I should have explained" spends words on the meta-conversation. Just add the reasoning and move on.

And if the interviewer probes first, treat it as an invitation rather than a criticism. They are giving you the chance to supply what was missing - take it fully, with the requirement, the alternative, and the cost.

The Question Behind The Question

When an interviewer asks "why Aurora?", they are rarely asking about Aurora.

They are asking whether you can justify a decision under scrutiny - which is a proxy for whether you will make defensible decisions on their team, and whether you will change your mind when presented with a better argument.

That reframes how to answer a challenge. The instinct is to defend the choice. The stronger response is to restate the reasoning and name what would change it: "the transaction requirement is what drives it - if checkout could be made eventually consistent with a saga, a key-value store would be viable and would scale writes better."

That answer shows the decision is conditional on the requirement rather than on preference, which is the actual thing being tested. A candidate who defends a choice regardless of the argument put to them has demonstrated something worse than a wrong choice.

Common Failure Modes

Warning: "Just" in front of a service name. Signals no decision was made.

The requirement never stated. The actual reason, missing.

No alternative named. Suggests a default.

The accepted cost never volunteered. The strongest available signal, unused.

The scaling path unstated. No evidence of thinking past today.

Answers that anyone could have produced. Scored accordingly.

Defending rather than explaining once the interviewer finds the weakness.

Apologising during recovery. Spends words on the meta-conversation.

The same compression on caches, sharding, and multi-region. Same failure, other clothes.

Naming a service whose central constraint you cannot state.

Why This Matters In An Interview

Interview: This is the highest-leverage habit in this course: every significant decision gets a requirement, an alternative, and a cost.

What interviewers are listening for:

The requirement before the choice.

A named and rejected alternative.

The accepted cost, volunteered.

The scaling path, and which decisions are expensive to reverse.

Common follow-ups:

"Why Aurora?" → The requirement first - joins and a cross-table transaction. Then the rejected alternative and why. Then the accepted cost: one writer, with partitioning as the path if write volume outgrows it.

"What's wrong with your design?" → Have an answer ready. Every design has a weakness, and a candidate who cannot name their own has not evaluated it. This is a common question and it is not a trap.

"You said you'd add a cache. Tell me more." → The cache key, the TTL, what happens on a miss storm, and how invalidation works. If those are not ready, the cache was a phrase rather than a design.

"What breaks first as this scales?" → Name it specifically and say at roughly what point. Database connections, usually - and knowing that is a much stronger signal than any service choice.

Practice

Exercise: Starter. Take a design you can give and, for every service you name, add the requirement that justified it. Time the difference - it will be under a minute.

Intermediate. For each significant decision, add the accepted cost using the two-clause formula. Practise until it is automatic.

Advanced. Record yourself giving a full design and mark every sentence that could have been produced without understanding. That proportion is what an interviewer is scoring.