Learning objectives
- Choose storage for an application with uploads, relational orders, and live rooms.
- How would you evaluate Hyperdrive for an existing database?
- Apply System of record to a customer decision and defend the tradeoff.
The mental model
Ask what must remain true when two requests race, a client retries, or a region observes an older value. Those questions are more useful than asking which database is fastest. R2 stores objects such as uploads and generated files. D1 offers relational storage. Workers KV favors distributed reads where stale values can be acceptable. Durable Objects combine a named coordination point with state. Hyperdrive helps Workers connect efficiently to an existing database rather than replacing that database. A real application may need several of these capabilities, but every additional store adds ownership, reconciliation, and recovery work that must be justified.
How it works
Start with access patterns and invariants: lookup by identifier, relational joins, large binary retrieval, concurrent updates, retention, and deletion obligations. Map each datum to a system of record. KV's eventual consistency makes it a poor default for a global lock, immediate permission revocation, or a scarce-inventory counter. A Durable Object can coordinate a named unit of state, but choosing one object for every customer can create an unnecessary concentration of traffic. D1 is an option for relational records; verify current database, query, and replication behavior against the workload rather than assuming it has every capability of a traditional database.
R2 is appropriate for objects; storing relational metadata there does not create convenient transactional queries. Hyperdrive addresses connectivity to supported existing databases, including connection management and optional query caching, while the source database retains its own schema and operational duties. Test cache freshness against write patterns. Avoid dual writes without a reconciliation strategy. A useful design documents authoritative ownership, acceptable staleness, idempotent writes, backup and restore expectations, and how deletion propagates to copies.
Use a small decision worksheet: object size, query shape, write frequency, concurrency, tolerated staleness, recovery, and existing expertise. An image upload and its relational ownership record may require separate stores; define what happens if the upload succeeds but metadata creation fails. A cleanup process or explicit pending state can reconcile the partial operation. The important question is which record proves the upload belongs to a user and how abandoned objects are eventually identified safely.
Applied example · hypothetical
Hypothetical scenario: a collaboration product stores attachments, workspace membership, presence, and downloadable exports. You consider R2 for attachments, relational storage for memberships, and a per-room Durable Object for live coordination. Read-mostly cosmetic preferences might fit KV; membership revocation requires stronger reasoning. The customer already has a substantial PostgreSQL database, so Hyperdrive may be an incremental option instead of a full migration. The prototype races concurrent membership changes and checks what an already connected client can still read after access is revoked.
In a customer engagement
During discovery, ask for the most expensive correctness failure: duplicate billing, lost documents, stale configuration, or unauthorized access. Have an engineer walk through a write and a subsequent read from another location. Then show a small data ownership table. Explain to finance that an extra store may reduce a specific cost while increasing operational and migration effort.
Interview relevance
A senior interview answer should reject a tempting but incorrect storage choice with a concrete invariant. Say why stale marketing preferences may be acceptable while stale authorization can be dangerous. Connect your existing database and systems experience to this reasoning without claiming production experience with D1 or Durable Objects unless you can substantiate it.
Common mistakes
- Using one store by habit
- Ignoring deletion across copies
- Calling it a database replacement
Key terminology
System of record — The authoritative source used to resolve disagreement about a particular business datum.
Coordination boundary — The unit of state and work that must agree on ordering or concurrency.
Read-after-write expectation — The application's requirement for what a read should observe after an acknowledged write.
Explain it without the page
- Choose storage for an application with uploads, relational orders, and live rooms.
- How would you evaluate Hyperdrive for an existing database?
Further reading
Sources explain the underlying concepts; examples and practice answers are original course material. Recheck current limits and plan eligibility before a real proposal.