• Order Management is responsible for orders
• Customer Management is responsible for customers

Subdomains can be classified as follows:

• Core — key differentiator for the business and the most valuable part of the application
• Supporting — related to what the business does but not a differentiator. These can be implemented in-house or outsourced
• Generic — not specific to the business and are ideally implemented using off the shelf software

The subdomains of an Order management include:

• Product catalog service
• Inventory management services
• Order management services
• Delivery management services

• Prepare phase — during this phase, all participants of the transaction prepare for commit and notify the coordinator that they are ready to complete the transaction
• Commit or Rollback phase — during this phase, either a commit or a rollback command is issued by the transaction coordinator to all participants

The problem with 2PC is that it is quite slow compared to the time for operation of a single microservice. Coordinating the transaction between microservices, even if they are on the same network, can really slow the system down, so this approach isn’t usually used in a high load scenario.

• Transform — Create a parallel new site with modern approaches.
• Coexist — Leave the existing site where it is for a time. Redirect from the existing site to the new one so the functionality is implemented incrementally.
• Eliminate — Remove the old functionality from the existing site.

• There are multiple calls for multiple microservices by different channels
• There is a need for handling different type of Protocols
• Different consumers might need a different format of the responses

An API Gateway helps to address many concerns raised by the microservice implementation, not limited to the ones above.

• An API Gateway is the single point of entry for any microservice call.
• It can work as a proxy service to route a request to the concerned microservice.
• It can aggregate the results to send back to the consumer.
• This solution can create a fine-grained API for each specific type of client.
• It can also convert the protocol request and respond.
• It can also offload the authentication/authorization responsibility of the microservice.

1. A composite microservice will make calls to all the required microservices, consolidate the data, and transform the data before sending back.
2. An API Gateway can also partition the request to multiple microservices and aggregate the data before sending it to the consumer.

It is recommended if any business logic is to be applied, then choose a composite microservice. Otherwise, the API Gateway is the established solution.

• Mobile API, which implements the API for the FTGO mobile client
• Browser API, which implements the API to the JavaScript application running in the browser
• Public API, which implements the API for third-party developers

• The command side handles the Create, Update, and Delete requests
• The query side handles the query part by using the materialized views

The event sourcing pattern is generally used along with it to create events for any data change. Materialized views are kept updated by subscribing to the stream of events.

The Event Sourcing pattern [8] defines an approach to handling operations on data that’s driven by a sequence of events, each of which is recorded in an append-only store. Application code sends a series of events that imperatively describe each action that has occurred on the data to the event store, where they’re persisted. Each event represents a set of changes to the data (such as AddedItemToOrder).

The events are persisted in an event store that acts as the system of record. Typical uses of the events published by the event store are to maintain materialized views of entities as actions in the application change them, and for integration with external systems. For example, a system can maintain a materialized view of all customer orders that are used to populate parts of the UI. As the application adds new orders, adds or removes items on the order, and adds shipping information, the events that describe these changes can be handled and used to update the materialized view. The figure shows an overview of the pattern.

• Choreography — When there is no central coordination, each service produces and listens to another service’s events and decides if an action should be taken or not. Choreography is a way of specifying how two or more parties; none of which has any control over the other parties’ processes, or perhaps any visibility of those processes — can coordinate their activities and processes to share information and value. Use choreography when coordination across domains of control/visibility is required. You can think of choreography, in a simple scenario, as like a network protocol. It dictates acceptable patterns of requests and responses between parties.

• Orchestration — An orchestrator (object) takes responsibility for a saga’s decision making and sequencing business logic. when you have control over all the actors in a process. when they’re all in one domain of control and you can control the flow of activities. This is, of course, most often when you’re specifying a business process that will be enacted inside one organization that you have control over.

A metrics service is required to gather statistics about individual operations. It should aggregate the metrics of an application service, which provides reporting and alerting. There are two models for aggregating metrics:

• Push — the service pushes metrics to the metrics service e.g. NewRelic, AppDynamics
• Pull — the metrics services pulls metrics from the service e.g. Prometheus

The solution is to introduce a transaction ID. Follow approach can be used;

• Assigns each external request a unique external request id.
• Passes the external request id to all services.
• Includes the external request id in all log messages.

To avoid code modification configuration can be used. Externalize all the configuration, including endpoint URLs and credentials. The application should load them either at startup or on the fly. These can be accessed by the application on startup or can be refreshed without a server restart.

With container technology, IP addresses are dynamically allocated to the service instances. Every time the address changes, a consumer service can break and need manual changes.

Each service URL has to be remembered by the consumer and become tightly coupled.

A service registry needs to be created which will keep the metadata of each producer service and specification for each. A service instance should register to the registry when starting and should de-register when shutting down. There are two types of service discovery:

• client-side : eg: Netflix Eureka
• Server-side : eg: AWS ALB.

The consumer should invoke a remote service via a proxy that behaves in a similar fashion to an electrical circuit breaker. When the number of consecutive failures crosses a threshold, the circuit breaker trips, and for the duration of a timeout period, all attempts to invoke the remote service will fail immediately. After the timeout expires the circuit breaker allows a limited number of test requests to pass through. If those requests succeed, the circuit breaker resumes normal operation. Otherwise, if there is a failure, the timeout period begins again. This pattern is suited to, prevent an application from trying to invoke a remote service or access a shared resource if this operation is highly likely to fail.

The blue-green deployment strategy can be implemented to reduce or remove downtime. It achieves this by running two identical production environments, Blue and Green. Let’s assume Green is the existing live instance and Blue is the new version of the application. At any time, only one of the environments is live, with the live environment serving all production traffic. All cloud platforms provide options for implementing a blue-green deployment.