Dark matter force: prefer ACID over BASE

microservice architecture   architecting   dark energy and dark matter  

New public workshop: Architecting for fast, sustainable flow - enabling DevOps and Team Topologies thru architecture. Learn more and enroll.

a dark energy, dark matter force

System operations are best implemented as ACID transactions. That’s because ACID transactions are simple and familiar programming model. The challenge, however, is that ACID transactions don’t work well across service boundaries. All participating services and their databases must, for example, support 2PC, which limits your choice of technologies and reduces availability since all participants must be available to commit the distributed transaction. Consequently, an operation that spans services must use eventually consistent (BASE) transactions (e.g. Sagas). The problem with BASE transaction is that, as I describe in my book, and in my distributed data patterns bootcamp, they lack of isolation (the ‘I’ in ACID) of ACID transactions and can be much more complicated to implement. As a result, the desire to implement an operation using an ACID transaction acts as an attractive force between the operation’s subdomains.

The strength of the force depends upon the operation

The strength of the force depends upon the details of an operation. Let’s consider a couple of examples

Example: createOrder() - Order Management and Fulfillment subdomains

Consider a createOrder() operation that does the following:

  1. Creates an Order in the Order Management subdomain
  2. Notifies the Fulfillment subdomain to deliver the Order

The downsides of distributing this operation across the Order Service and the Fulfillment Service are fairly minor. The createOrder() operation could be implemented by a simple choreography-based saga. The Saga consists of two steps:

  1. The Order Service creates an Order and publishes an OrderCreated event
  2. Fulfillment Service handles the OrderCreated event and schedules the delivery of the Order

In this example, the lack of ACID transactions is not a significant problem. Let’s now look at a more complex example.

Example: createOrder() - Order Management, Customer Management, Inventory Management and Fulfillment subdomains

Consider a more complex version of the createOrder() operation that does the following:

  1. Creates an Order in the Order Management subdomain
  2. Reserves credit in the Customer Management subdomain
  3. Reserves inventory in the Inventory Management subdomain
  4. Schedules a shipment the Fulfillment subdomain to deliver the Order

Let’s imagine that these four domains are implemented as separate services and that createOrder() were implemented using a Saga. While this might seem simple, it’s actually quite complex:

  1. The first challenge is that steps 2 and 3 can fail. As a result, steps 1 and 2 need compensating transactions to undo the changes that were previously committed.
  2. The problem with compensating transactions that now the saga might update entities twice - once in the regular transaction and then again in the compensating transaction. As a result, there’s the possibility of what is termed a dirty read. Another transaction or saga could read a Order or Customer after the regular transaction and before the compensating transaction has been executed. It’s really what is essentially uncommitted changes that can lead to incorrect results. Preventing dirty reads requires additional complexity in the saga implementation.

A simpler solution would be to eliminate the need for compensating transactions by collocating the Order Management, Customer Management, and Inventory Management subdomains in a single Order Service. The drawback of this approach is that it might violate one or more of the dark energy forces.

Using eventual consistency requires careful design

As you can see, using eventually consistent transactions (BASE) can be simple in some cases and complex in others. Unlike ACID, using eventual consistency can require careful design and analysis to prevents bugs caused by the lack of isolation. Moreover, you also need to determine whether the additional complexity is a worthwhile trade-off. This is one of the benefits of using the Assemblage design process.

microservice architecture   architecting   dark energy and dark matter  

Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

New workshop: Architecting for fast, sustainable flow

Enabling DevOps and Team Topologies thru architecture

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for my September 2024 online workshops....


I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon WURMXAJV to sign up for $95 (valid until July 19th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter

BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,

The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.

Join the microservices google group