What to choose, when, and what you give up.

Caches

• The same rows are read thousands of times a second and the database is the bottleneck.
• Reads must come back in under a couple of milliseconds.
• You need counters, sessions or a leaderboard that many servers share.

Distributed key-value

• Billions of records, or writes arriving faster than one database server can take them.
• Most reads start from a key the app already knows: a customer, a device, a tenant and an hour.
• The app can live without joins, and can keep the records that change together inside one record.

Work queues

• A user-facing request does slow work it doesn't need to wait for, like sending an email or resizing an image.
• Several services need to know about the same event, like an order being placed.
• Work arrives in bursts, and the buffer must hold it without silently losing anything.

Search

• People type words, not ids, and expect the right product first even with a typo.
• Results need counts per brand or price band next to them, and filters that update as you click.
• The database holds the real price and stock. A search copy needs a relay to carry every change, and it can show an old price for a while.

Relational databases

• Orders, customers and stock relate to each other, and an order must never half-save.
• One machine takes every write, and you're wondering how far that goes before it breaks.
• Someone has said 'just use Postgres' and someone else has said 'Aurora', and nobody has said why.

Distributed SQL

• One primary takes every write, and it already runs on the biggest machine you can buy.
• Customers on both coasts place orders, and the shop must keep selling if one coast's region is lost.
• The app needs SQL and transactions, and the word shard has come up in the code.

Document databases

• Every screen reads the order whole, and the app changes one field deep inside it.
• Orders differ in shape: some have gift wrap, some have three addresses, some have none.
• Emma's phone must show the order move from packed to shipped without asking again.

Warehouses

• A report that scans months of orders makes checkout slow, or times out.
• Someone says 'put it in a warehouse', and you don't know what that costs or which one.
• Finance, marketing and data science each export their own copy, and the totals disagree.

Real-time analytics (OLAP)

• A dashboard must show the last few minutes, but the reports it reads are a night old.
• The same count runs thousands of times a second, and the order database can't keep up.
• Someone says 'put it in ClickHouse' or 'use Druid', and you don't know what the difference is.

Time series

• Metrics from every server pile up in Postgres, and the 'last 5 minutes' query gets slower every week.
• Someone says 'just use Prometheus', and someone else says Prometheus can't keep 13 months.
• A new label took the series from 60,000 to 2 million, and the store ran out of memory.

Graph databases

• A query that follows links three or more steps has grown into a page of joins, and it takes seconds.
• Fraud asks 'is this order linked to a banned account through a shared card or address?', and nobody can bound the SQL.
• Someone says 'this is a graph problem', and nobody knows if Postgres can still do it.

Vector retrieval

• The product page needs 'similar items', and keyword search misses things that mean the same with different words.
• A chatbot must find the right help articles before it answers, and someone said 'you need a vector database'.
• There are embeddings in a Postgres column, and the similarity query got slow past a million rows.

Object and file storage

• Product images sit on one server's disk, and a second server can't see them.
• Invoices are stored in a database column, and the database backup is now mostly PDFs.
• Someone says 'put it in S3', and you don't know what changes for the code that writes and reads files.

Stream processing

• A fraud check runs once a minute, but the hold must go out within two seconds of the order that trips it.
• A live count is kept in a service's memory, and a restart resets it to zero.
• Someone says 'use Flink', and you don't know whether a library in your app or a SQL view would do.

Durable workflows

• Four calls are chained in one request, and a deploy in the middle leaves an order paid for but never shipped.
• Retries live in a cron job that reruns everything, and some customers get two emails.
• Someone says 'use Temporal', and you don't know whether a job queue, a state machine on AWS or a diagram engine would do.

Coordination

• A nightly job ran twice because two copies of the service started it at 2 am.
• A Redis lock expired during a slow step, a second worker took it, and both wrote.
• Someone says 'use ZooKeeper', and you don't know whether a database lock, a Redis key or a consensus cluster would do.

Real-time delivery

• The page polls the server every two seconds, and 20,000 tabs make 10,000 requests a second, nearly all answered 'no change'.
• Emma's phone lost the network for a moment, and her tracking page never showed 'shipped' until she refreshed.
• Someone says 'use WebSockets', a connection the server can write to, and nobody knows if that means your code, a library, a server or a hosted service.

Traffic routing

• A deploy restarts the proxy and every open connection drops, including the tracking pages.
• One hung instance keeps getting a third of the requests until someone notices.
• Someone says 'put NGINX in front'. You don't know if that means a proxy you run, a cloud load balancer, an API gateway, or a CDN.

Architecture styles

• Two teams wait for each other's release.
• One part needs ten times the machines of the rest.
• A change in one place breaks a page nobody expected.

Unique IDs

• Several servers need ids without asking one shared counter.
• An id in a URL lets people guess other orders, or count them.
• Someone wants to change the primary key format, and nobody knows what the index will do.

Multi-region data

• A whole region can go down, and the shop must keep taking orders.
• Customers far from the database wait too long for every page.
• A regulator says some customers' data must stay in one place.