2.4SOA and microservices

The claim "switching to microservices makes a system flexible and scalable" is common, but it is only half true, ignoring the cost of splitting. Microservices trade independent per-service deployment and partial scaling for a heavy cost: more inter-service communication, eventual consistency of data, and greater operational complexity. A system architect's essential role is not "choosing microservices" but judging, against the requirements (release frequency, team structure, scaling characteristics), whether a monolith or microservices is more appropriate, and confirming the organization is prepared to absorb the distribution tax.

2.4.1The SOA concept

• SOA (service-oriented architecture) is a design philosophy that implements business functions as independent "services" and connects them loosely through standardized interfaces (such as web services). It offers the benefit of making services easy to reuse as building blocks and easy to integrate with existing systems, but it also tends to depend on a common enterprise backbone (an ESB, or enterprise service bus), which carries the risk that the backbone itself becomes a single point of failure or a bottleneck for change.

2.4.2Microservices and the splitting judgment

• Microservices push the SOA concept further, splitting a system down to a granularity where each service can be independently built, deployed, and scaled. Each service ideally owns its own data store, giving the benefit of splitting teams by function and letting release cycles run independently, at the cost of increased inter-service network communication, the burden of maintaining data consistency, and operational complexity such as distributed tracing.
• The convention is to split service boundaries along business domain lines (order, inventory, payment, etc.—units that have independent reasons to change), not along technical layers (screen/logic/data). Housing functions with different reasons to change inside the same service means a change to one impacts the other, forfeiting the benefit of independent deployment, so the domain-driven design (DDD) concept of a bounded context is the guiding principle for the splitting judgment.

2.4.3The distribution tax: eventual consistency and operational complexity

• Because each microservice owns its own data store, an update spanning multiple services cannot be guaranteed with ACID in a single transaction. Instead, the design must accept eventual consistency—all services' data eventually converges to agreement, but data may temporarily disagree across services immediately after an update.
• Distribution also brings problems such as inter-service communication failures (partial failures), out-of-order processing, and duplicate message delivery. Furthermore, the more services there are, the greater the operational burden of deployment, monitoring, fault isolation, and distributed tracing becomes, so adopting microservices without an organizational setup (DevOps practices, monitoring infrastructure, etc.) capable of handling this operational complexity can actually slow down incident response.

A system architect has been assigned to modernize the platform of an e-commerce site currently run as a monolith. Leadership has requested that "the order, inventory, payment, and shipping teams be able to release independently without affecting each other," and that "during a sale, only the order function's load spikes, so we want to scale just that part intensively." These two requirements—independent release and partial scaling—are difficult to achieve with a monolith, making a move to microservices, split and independently deployable by function (service), a reasonable judgment. When considering service boundaries, the architect avoided splitting along technical layers such as "a presentation service," "a business-logic service," and "a data-access service," and instead adopted a design that splits along business-domain boundaries: an order service, an inventory service, a payment service, and a shipping service. This lets teams and release cycles be separated along units with independent reasons to change—for instance, a change to payment logic no longer impacts the inventory team's work. Next, for the interaction where the order service asks the inventory service to allocate stock, the architect must switch to a design premised on eventual consistency, giving up single-transaction ACID consistency. Concretely, on order confirmation the order service sends an allocation request to the inventory service; once allocation completes on the inventory service's side, it returns an "allocation completed" event to the order service asynchronously, and the order status is allowed to sit in a temporarily indeterminate "allocation in progress" state for the short window until allocation completes. If stock is insufficient, the design also needs a compensating transaction that cancels the order upon receiving an "allocation failed" event. Furthermore, because the number of services grows to four, the operational complexity of identifying which service is at fault when a failure occurs increases, so the architect built into the migration plan the introduction of distributed tracing and the establishment of a monitoring setup that lets each team handle on-call response. This is because proceeding with microservices without preparing this operational structure risks delaying root-cause isolation during an incident, actually lowering availability.

2.4.4Section summary

• SOA loosely couples services via standard interfaces; microservices split further, down to a granularity that is independently deployable
• Splitting is done along business domain boundaries (units with independent reasons to change), not technical layers
• Adopting microservices carries the distribution tax of eventual consistency and operational complexity; depending on the requirements, a monolith can still be more appropriate