Should I use choreography or orchestration?
1. Should I use choreography or orchestration?
Now that you've learned how choreography and orchestration work in Google Cloud, which pattern is better, choreography or orchestration? Like many application architecture decisions, the answer is "it depends." The better question is "when should I use choreography, and when should I use orchestration?" When you use event-based choreography, you rely on the receiving service to control the communication. When Service A completes some work and sends an event, Service A has no idea whether any other service will act on that event. It is not the responsibility of Service A to know whether any downstream service or services are consuming the event. Using Eventarc, most Google Cloud or custom services can act as an event producer. A receiver of an event, though, must understand the details of the event to be consumed. In the example shown here, Service B consumes the event that was sent by Service A. Service B understands the formatting of the event and how to act on the event. Service B might also know that the event was sent by Service A, but it is not directly coupled to Service A. It's possible to implement the product ordering flow using choreography. Each service would send an event to indicate readiness for the next step in the process. The "out of stock" decision points could be implemented by specific services, deciding whether to send the "in stock" or "out of stock" events. However, an enterprise order system requires visibility, error handling, and retries. Implementing these features in an event-based solution can be difficult. How would you troubleshoot issues with an event-based system? What happens if the process somehow aborts between locking the inventory in the database and updating the inventory and order? How do you make sure that requests are successfully sent to suppliers? With orchestration, each workflow execution is tracked separately. The ordering process logic, which may be built using many services or functions, is defined in a single location. Retries and error handling can provide a reliable order handling flow. Sometimes, your architecture requires decentralized control which cannot be provided by a single orchestrated workflow. With orchestration, if these services are built and managed by different teams or organizations, shared management of the central orchestration process can be difficult. Choreography provides decentralized control, where each of the services or applications connects to the others using events. Each service can be separately managed by a different team or organization. Orchestration is a strong pattern when you want to control a complex process that you can manage centrally. Choreography is more appropriate when combining separate, decentralized services and applications using events, or when you want to leverage events from Google Cloud services. You may find that using Workflows and orchestration provides the visibility, error handling, and reliability required to create your complex services. You can use Eventarc to send events between the services. In the example shown here, the Order, Fulfillment, and Marketing services are implemented using Workflows. Event triggers between the services and the detection of new order files being uploaded into a Cloud Storage bucket are implemented using Eventarc.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.