Skip to content
Course contents

There Is No Such Thing As "The Database"

The thing you draw as one box on the architecture diagram is six systems in a trenchcoat, and you are the one holding it together.

Lesson 1 of 58 min read

By the end of this lesson you can

  • Name the components that hide behind the word "database" in a typical application
  • Explain why the guarantees of a composed system are weaker than the guarantees of its parts
  • Identify who is responsible for correctness when data lives in two places at once

Draw the architecture of the last thing you built. There is probably a box labelled database, with an arrow going into it.

That box is a lie, and it is a useful place to start, because almost everything that goes wrong in a data-intensive system goes wrong in the gap between what the box promises and what the arrangement of parts behind it actually delivers.

What is actually in the box

A modest web application, three years old, with real users, typically stores its data across something like this:

  • A relational database, holding the records the business would be sued for losing.
  • A cache, holding a copy of the expensive-to-compute answers, so the database is not asked the same question four thousand times a second.
  • A search index, holding a different copy of the same data, arranged so that a human can find a record by typing three-quarters of its name.
  • A queue or stream, holding work that has been accepted but not yet done — emails to send, thumbnails to generate, invoices to reconcile.
  • An object store, holding the things too large to put in a row: uploads, exports, backups.
  • An analytics warehouse, holding a third copy of the same data, arranged so somebody can ask how many of them there were last Tuesday.

None of these is the database. Each is a specialised tool with its own durability guarantees, its own failure modes, and its own opinion about what should happen when two people write at once.

The idea

Once your data lives in more than one system, you have stopped being an application developer and started being a database designer. The composite system — the one your users actually experience — has no documentation, no vendor, and exactly one maintainer.

Guarantees do not compose

Here is the uncomfortable part. Your relational database guarantees that a committed write is durable. Your search index guarantees that a committed write is durable. Put them together with “write to the database, then update the index” and the pair guarantees nothing of the sort.

Consider the sequence:

1. INSERT INTO products ... ✓ committed, durable
2. searchIndex.add(product)  ✗ process killed here

The record exists. It is not findable. No individual component has broken its promise — the database kept its data, the index kept its (older) data — and yet the system as a whole is now wrong in a way that no amount of reading either system’s documentation would have warned you about.

So what is a “data system”?

The useful definition is not about the technology. It is about the boundary:

Working definition

A data system is whatever collection of tools you have assembled such that, from the outside, it appears to store and return your application’s data correctly. The boundary is drawn by the promise you make to your users, not by the vendor’s product page.

This matters because it puts the responsibility in the right place. When a customer says “I saved it and it disappeared,” it is no defence that PostgreSQL was working correctly. You designed the composite. It is yours.

Three questions worth more than any technology choice

Everything in this course comes back to three properties, which get a lesson each:

Reliability. The system keeps working correctly even when things go wrong. Not if — when. Disks fail, networks partition, and somebody will run the migration against production.

Scalability. As the load grows, there are reasonable ways to keep performance acceptable. Note the weasel words: load and performance both have to be defined before this sentence means anything, which is most of what the next two lessons are about.

Maintainability. People can work productively on the system over time — including the people who arrive after you leave, who will have no idea why any of it is like this.

Check yourself

Your app writes an order to Postgres, then publishes an `order.created` event to a queue. The process is killed between the two. Which statement is true?

What to take away

The word “database” hides a system you designed and are responsible for. For the rest of this course, when you read a guarantee, ask the two questions that follow from this lesson: whose guarantee is it, and what happens at the seam between it and the next component along.

If you want to go deeper

Finished this one?

skip for now