You are receiving this email because you subscribed to microservices.io

On Wednesday, January 22, 2025 at 6pm, I'll be giving a talk in Melbourne Australia.The talk is: Enabling DevOps and Team Topologies: Architecting for Fast Flow. I hope to see you there.

Learn about the service collaboration patterns (Saga, API composition, etc) in my online, self-paced bootcamp. It's available for USD $95 - limited time early. Find out more and enroll.

I'm available for consulting and workshops at your organization. Learn more

A phone company's customer experience: a great example of undesirable tight runtime coupling

There are various types of undesirable coupling that can occur in a microservice architecture. Recently I wrote about how the The launch status check: a great example of loose design-time coupling. Another type of coupling that can occur is runtime coupling, which affects the runtime behavior of an application.

What is runtime coupling?

Runtime coupling is one of the reasons that the famous computer scientist Leslie Lamport once wrote:

A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.

It occurs in a microservice architecture when service X (e.g. the Order Service) cannot respond to a request (e.g. POST /orders) until another service Y (e.g. Customer Service) has responded to it.

Tight runtime coupling increases latency and reduces availability. In the worst case, you can create an architecture that behaves like a string of Christmas tree lights: if one light goes out, they all go out. While tight runtime coupling is sometimes a worthwhile trade-off, such as in the API Composition pattern, the goal when designing a microservice architecture should usually be to minimize runtime coupling.

A real-world example of tight runtime coupling

A recent experience with my phone company illustrates the problem of tight runtime coupling. I wanted to change some features of my phone plan but was unable to do it online and so had to call ‘customer service’. I finally got through to a human who eventually put me on hold while talking with “other departments” who could make the changes.

After an hour on the phone, the customer service representative told me that they couldn’t make the changes because of an internal system problem and that the folks who could fix it didn’t work weekends and that I needed to call back on Monday. Essentially, the end-to-end flow ‘me -> customer service rep -> other departments’ is an example of tight runtime coupling. We all needed to be available at the same time in order to make the changes.

What’s even worse is that this was not the first time I requested these changes. After what I thought was a successful call, the changes were simply not made. The VP of Customer Service is certainly doing “a heckuva of job”.

A less runtime coupled customer experience

Ignoring the fact that I should have been able to make the changes online, what should a less runtime coupled customer experience look like? It’s actually quite simple. I should have been able to hang up after the customer service representative captured my request. The changes should have been made in the background, presumably by routing tickets to the various departments. They could have even phoned to notify me that the work was done.

Service collaboration patterns

Let’s now look at a version of the customer and order example that is less runtime coupled. There are two service collaboration patterns that can reduce runtime coupling when implementing commands: the saga pattern and the command-side replica pattern. The customer and order example needs implement the POST /orders request using the saga pattern since it updates both the Customer Service and the Order Service.

The saga-based implementation of POST /orders works as follows:

1. Client makes a POST /orders request to the Order Service
2. The Order Service creates the Order in PENDING state and responds to the with a 200 (or 202) response containing the Order ID
3. The Order Service and Customer Service exchange messages to complete the creation of the Order, which ends up in the ACCEPTED or REJECTED state

Since the initial response no longer contains the operation’s ultimate outcome, the client can either periodically poll the Order Service for the status of the Order or the Order Service can send a message to the client when the Order is complete.

See the Saga pattern for the two different ways of implementing the Create Order Saga.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help

Chris Richardson Consulting, Inc | 180 Rishell Drive, Oakland, CA 94619 Unsubscribe you Update Profile | Constant Contact Data Notice Sent by chris@chrisrichardson.net powered by Try email marketing for free today!