Stop 15 · Interview PreparationServices & Technical · 3/3

Database Questions

Part of the Cloud Computing Roadmap

In short

"RDS or DynamoDB for this?" is really asking "do you choose databases by habit or by access pattern?" Start from how the data is read and written, and the answer usually picks itself.

'How would you choose between RDS and DynamoDB for this use case?' — testing Phase 6's database selection judgment against a specific scenario.

The blob character in a doctor's coat with a stethoscope writes on a prescription pad at a desk.

Think of it like this

The doctor asks symptoms first

A good doctor doesn't prescribe his favourite medicine to every patient. He asks where it hurts, since when, any allergies. Only then does he write the prescription. Choosing a database works the same way: symptoms, meaning access patterns, before medicine.

Watch it happen

Picking a database from the access pattern

How is data used?
Joins, transactions
RDS / Aurora
Key lookups, scale
DynamoDB
Hot repeat reads
Redis cache
Analytics on TBs
Redshift/BigQuery

1/5Start with questions: what are the main queries, how much data, how many requests, how strict is consistency?

The big ideas

What you need to know

List the queries first

Write the top five queries the app runs. Relational fits flexible queries; DynamoDB needs them known upfront.

Replicas vs Multi-AZ

Read replicas spread read load. Multi-AZ standby is for failover. Mixing these up is a common slip.

Scaling paths differ

Relational usually scales up and adds replicas. DynamoDB scales out through partitions, if keys are spread well.

Many apps use several

Postgres for orders, Redis for sessions, a warehouse for reports. Saying "it depends, and here's on what" is right.

How it works

Answering "RDS or DynamoDB?"

  1. 1

    Access patterns

    Ask which queries matter most and whether they're by key or need joins and filters.

  2. 2

    Scale and traffic

    Ask about requests per second and data size. Spiky, huge key-value traffic favours DynamoDB.

  3. 3

    Consistency

    Money and inventory often need transactions across rows, which is natural in SQL.

  4. 4

    Choose and caveat

    "RDS Postgres, because reporting needs joins. If carts get huge traffic, I'd move them to DynamoDB."

Save yourself the pain

Common mistakes

Oops

Picking DynamoDB because it "scales infinitely" without knowing the queries.

Do this instead

DynamoDB shines when access patterns are known. Ad-hoc queries on it get slow and costly.

Oops

Saying read replicas give high availability.

Do this instead

Replicas mainly help reads. For automatic failover, mention Multi-AZ standby.

Your mission

Three apps, three choices

~25 min

Quick check

A game stores each player's score and reads it by player id millions of times a minute. No joins. Best fit?

Go deeper

  1. 1Review Phase 6 and practice justifying a database choice for 2-3 different hypothetical workloads.
  2. 2Prepare to discuss read replicas and Multi-AZ trade-offs concretely.
  3. 3Practice explaining caching's role in reducing database load.

More services & technical at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge