Architectural Design Decisions and Case Studies (Monolith vs. Distributed)

Key Insight

Architects must make fundamental determinations regarding system structure. The first is deciding between a monolith and a distributed architecture, based on whether a single set of architecture characteristics suffices for the entire system or if different parts require distinct characteristics. For monoliths, a single relational database or a few are common, while in distributed architectures, architects must decide which services persist data and how data flows for workflows. The next critical decision involves communication styles between services: synchronous or asynchronous. Synchronous communication is generally more convenient but can hinder scalability and reliability, whereas asynchronous offers performance and scale benefits but introduces complexities like data synchronization, deadlocks, and debugging. Architects are advised to default to synchronous communication and employ asynchronous only when necessary to address specific architectural needs.

The 'Silicon Sandwiches' case study illustrates monolithic design choices. For this simple application with a limited budget, a single quantum was deemed sufficient. A modular monolith design featured domain-centric components with a single relational database and a web-based user interface, with considerations for future migration to a distributed architecture by separating database assets. When customizability was a key characteristic, a microkernel style was chosen. This design consisted of a core system with domain components and a single relational database, where customizations were implemented as decoupled plug-ins, each potentially with its own data. This also utilized the Backends for Frontends (BFF) pattern, where API layers served as thin microkernel adaptors to translate generic backend information into device-specific formats for richer user experiences, with communication remaining synchronous due to modest performance requirements.

For more complex scenarios, the 'Going, Going, Gone' (GGG) case study exemplifies distributed architecture. This system required differing architecture characteristics for various roles (e.g., auctioneer, bidder) and ambitious levels of scale, elasticity, and performance. Microservices were chosen over event-driven architectures due to their superior support for differing operational characteristics, despite potential performance challenges from orchestration. The GGG design involved several distinct services like BidCapture, BidStreamer, BidTracker, Auctioneer Capture, and Payment. Strategic use of asynchronous communication was crucial to accommodate differing operational characteristics between services, such as a Payment service processing a new payment every 500 ms, ensuring reliability for critical yet fragile components. This design resolved into five quanta (Payment, Auctioneer, Bidder, Bidder Streams, and Bid Tracker), demonstrating how quantum analysis helps define service, data, and communication boundaries, ultimately achieving a robust architecture by intelligently leveraging microservices, events, and messages to find the 'least worst set of trade-offs'.