Service-Based Architecture Fundamentals and Design

Key Insight

Service-based architecture (SBA) is a hybrid of microservices, recognized for its architectural flexibility and pragmatic approach, offering lower complexity and cost compared to other distributed architectures like microservices or event-driven styles. Its basic topology features a distributed macro layered structure, comprising a separately deployed user interface, remote coarse-grained services (known as domain services) that are also separately deployed, and a single, monolithic database. Services are typically deployed similarly to monolithic applications (e.g., EAR, WAR files), thus usually not requiring containerization, although Docker deployment is possible. Applications using SBA generally consist of 4 to 12 services, with an average of about 7, all sharing this central monolithic database. While often a single instance of each domain service exists, multiple instances can be deployed for scalability, fault tolerance, or throughput, necessitating load balancing between the user interface and service instances. Access to services from the user interface commonly uses remote protocols like REST, but messaging, RPC, or SOAP can also be employed. Direct service access via a service locator pattern embedded in the user interface, API gateway, or proxy is frequent, though an API layer (proxy or gateway) can also intermediate requests.

Domain services in SBA are coarse-grained and commonly designed using a layered architecture, incorporating an API facade, a business layer, and a persistence layer. Another prevalent design method is to domain partition each service into sub-domains, mirroring the modular monolith architecture style. Regardless of the internal design, each domain service must expose an API access facade, which the user interface interacts with to execute business functionality. This facade is responsible for orchestrating the business request internally. For instance, a 'place order' request from the user interface, received by the API access facade within an 'OrderService' domain service, would internally orchestrate actions such as placing the order, generating an order ID, applying the payment, and updating product inventory for ordered items. This internal, class-level orchestration contrasts sharply with the microservices architecture style, where the same request would likely involve orchestrating multiple separately deployed remote single-purpose services, highlighting a fundamental difference in service granularity.

The coarse-grained nature of domain services in SBA enables the use of traditional ACID (atomicity, consistency, isolation, durability) database transactions with commits and rollbacks, ensuring robust database integrity within a single domain service. This provides a higher level of data integrity compared to highly distributed architectures like microservices, which often feature fine-grained services and rely on BASE (basic availability, soft state, eventual consistency) transactions, which prioritize eventual consistency. For example, in a catalog checkout process within SBA, if a credit card payment fails due to expiry, the entire transaction within the 'OrderService' can be rolled back atomically, maintaining a consistent state. In contrast, a microservices setup might involve separate 'OrderPlacement' and 'PaymentService's; if the payment fails after the order is created, the system can enter an inconsistent state, with the order inserted but not approved, and inventory status becoming ambiguous. While SBA offers better data integrity, a trade-off exists: changes to coarse-grained functionality (e.g., order payment) necessitate testing the entire service, introducing more risk and scope for potential issues compared to microservices, where changes are isolated to smaller, single-responsibility services, minimizing impact on other functionalities.