Almost two years ago, in my Dual Write post, I introduced a few patterns for handling dual writes and said I might explore them in more detail later. That took a while, but here we are. If you haven’t read that post, it covers the problem and why simply reordering the writes or retrying in memory doesn’t solve it.

The idea behind these patterns is simple: when we can’t make two writes to independent systems atomic, we make one follow from a durable record of the other. In the e-commerce example from the previous post, the search service indexes a listing after its database record has been saved, or after an event to create it has been durably published. That distinction matters for the listen-to-yourself pattern, as we’ll see later. Either way, the search service needs a reliable way to learn about the listing so buyers can find it.

Have you ever studied or worked with databases, come across abbreviations such as ACID, BASE, and CAP, and wondered what they mean? I have, and this post is the result of my research into them.

Is CAP a type of headwear?

CAP stands for Consistency, Availability, Partition-tolerance. Eric Brewer introduced it in a talk in 2000. He argued that when a partition disrupts network communication between nodes in a distributed system, the system must choose between consistency and availability. It cannot guarantee both. What are these properties, and why can we not have both?

When working on backend systems, we often follow a common pattern for handling incoming data. A server receives data from a message broker or an API, processes it according to the business rules, and inserts or updates it in the database. It then sends the processed data to the next server through a message broker or an API. This pattern is called dual write, sometimes also called multi-write or sync-write.