Database Management and Architectural Characteristics of SBA

Key Insight

Services within a service-based architecture (SBA) typically share a single, monolithic database, which is manageable given the usual 4 to 12 services per application and generally doesn't cause issues with database connections. However, this database coupling can present significant challenges when making database table schema changes. If not properly managed, a schema change can potentially affect every service, leading to costly and effort-intensive database modifications. A common, though least effective, practice is to store shared class files representing database table schemas (entity objects) in a single custom shared library (e.g., JAR or DLL) used by all domain services. Any modification to table structures then requires updates to this shared library and subsequent redeployment of every service, even those unaffected by the change. While shared library versioning helps, it doesn't fully resolve the impact. A more effective mitigation strategy involves logically partitioning the database and reflecting this partitioning through federated shared libraries. For instance, the database can be partitioned into domains like 'common', 'customer', 'invoicing', 'order', and 'tracking', with corresponding shared libraries. Changes to a table in the 'invoicing' domain would then only impact services utilizing the 'invoicing' shared library, leaving others unaffected. A 'common' domain and its corresponding shared library, accessed by all services, is frequent; changes to these common tables require cross-service coordination, and access restrictions (e.g., locking in a version control system for the database team) can help manage their impact. Logical partitioning in the database should be as fine-grained as possible while maintaining well-defined data domains to better control changes.

SBA is a domain-partitioned architecture, structuring the system based on business domains rather than technical layers. Changes made within a specific domain (e.g., item assessment) impact only that service, its user interface, and its database, with no need for modifications elsewhere. As a distributed architecture, SBA can have one or more quanta (isolated deployment units). While multiple services sharing a database or user interface might form a single quantum, federating the user interface and database can result in multiple quanta within the system (e.g., an electronic recycling application might have two quanta: one for customer-facing operations and another for internal operations). SBA, while lacking five-star ratings, achieves strong four-star ratings in several critical areas. Its ability to break an application into separately deployed domain services significantly boosts agility (faster change), testability (better coverage due to limited scope), and deployability (more frequent, lower-risk deployments), which collectively improve time-to-market. Furthermore, fault tolerance and overall application availability also receive four stars because domain services are typically self-contained and minimize interservice communication by leveraging shared databases and code. This isolation means that the failure of one domain service usually does not impact others. The coarse-grained nature of domain services also contributes to higher reliability by reducing network traffic, the number of distributed transactions, and overall bandwidth usage.

Despite its strengths, SBA's scalability rates three stars and elasticity two stars, primarily due to the coarse-grained nature of its services. While programmatic scalability and elasticity are feasible, more functionality is replicated compared to fine-grained services (like microservices), making it less efficient in terms of machine resources and cost-effectiveness. Often, single service instances are sufficient, with scaling only applied to services requiring higher throughput or failover (e.g., customer-facing 'Quoting' and 'Item Status' services might scale, while other operational services remain single instances). SBA distinguishes itself from more complex distributed architectures (e.g., microservices, event-driven, space-based) through its simplicity and lower cost, making it one of the easiest and most cost-effective distributed architectures to implement. However, this cost saving and simplicity come with a trade-off in some architectural characteristics, where higher-cost, more complex architectures tend to achieve better ratings. SBA aligns well with domain-driven design, as its coarse-grained, domain-scoped services naturally compartmentalize functionality into manageable software units, simplifying changes. It excels in preserving ACID (atomicity, consistency, isolation, and durability) transactions better than most other distributed architectures due to the coarse-grained nature of its domain services, with transactions typically scoped within a single domain service. Sagas and BASE transactions are only required when the user interface or API gateway orchestrates multiple domain services. Finally, SBA offers a good level of architectural modularity without the complexities associated with fine-grained services, such as orchestration (coordinating services via a central mediator) or choreography (services communicating directly), which are often necessary in architectures with more numerous, finer-grained services to complete business transactions.