Thinking past the days of large monoliths, now we talk about microservices. In the previous chapter we saw the benefits of distributing services so that components can be released independently, as well as the move away from the cyclomatic complexities that make releasing changes to a system hard. 

But a distributed system isn't always the answer if you still have to centrally manage the orchestration, order of processing, and consistency of data. Microservices that are tightly coupled can introduce crazy amounts of dependencies, so you may find that you're actually no better off than when you had a monolithic architecture. What I'm alluding to here is the request-driven approach, which can be both synchronous or asynchronous. This is also known as event-command, where you're asking another system to do something based on something you have been asked to do:

To explain the underlying principles at play here, let's look at the example of RESTful APIs that front the functionality for a nano or microservice. Let's say we have a service that is responsible for creating new customer accounts for a storefront application. When a new request is received to create a new account, the service must call out to multiple other services that are responsible for doing their thing. Some of these could include the fraud service for checking the integrity of the request, the email service for setting up and validating their address, and the user profile service, which creates new entries in the ERP and CMS systems. This example includes loosely coupled services—they can all be deployed and maintained independently with their own data—but the caller service is still responsible for knowing how to communicate and request work from the downstream services. This creates a dependency on multiple levels as well.

These dependencies lead to questions that we may not have the answers to yet:

• Does the caller service wait for a successful response or have a timeout so that it can gracefully degrade a service in the event of a failure?
• How does the caller service maintain awareness of downstream REST interfaces if they are allowed to be changed independently?
• How can the caller roll-back any state that was changed if a transaction is interrupted?
• Can a service use a circuit breaker to disrupt the chain of events if a failure happens?

What we want to achieve is loosely coupled, modular services that have APIs and enable segregation of responsibilities and domains, but we also want to drive down these dependencies so that they become increasingly real-time. Instead of orchestrating and coordinating a dance of the services, what if the services only react to the things they are interested in?

This brings us to what we will cover in the next section: event-first. This is a different way of thinking about what an event communicates to the subscriber.