In the last chapter, we explored the constraints that describe the Microservices Abstract Style. The conclusion of that chapter introduced the concept of “Domain to Architecture Isomorphism” and how microservices styles are generally not well suited to workflow-driven workloads. The root of this weakness lies in the architectural topology of the microservices style, which first emerged in request-driven systems. In such systems, the overwhelming majority of functionality is designed to be invoked through some kind of request that initiates a defined behavior and then returns a response. For example, if we return to our ecommerce microservices example, clicking “add to cart” will initiate a request to the Cart service to perform that action. The Cart service will, in turn, update the state of the customer’s cart in the database before returning a response. In a microservices style, each service will handle a narrow set of requests.