Architectural Styles: From Monolith to Distributed

Described as “a hybrid of the microservices architecture style… one of the most pragmatic architecture styles”. It is a distributed macro layered structure with three pieces: a separately deployed user interface, separately deployed remote coarse-grained domain services, and a monolithic, centrally shared database.

Services deploy like any monolith (EAR, WAR, assembly) and need no containerisation. Because they share one database, the number of services within an application context generally ranges between 4 and 12, averaging about 7. Usually there is a single instance per domain service, with more only for scale, failover or throughput.

• Access: remotely via REST — or messaging, RPC, SOAP — usually directly, with a service locator pattern. An optional API layer (reverse proxy or gateway) can be added for external exposure and cross-cutting concerns: metrics, security, auditing, service discovery.
• Service design: each domain service typically uses an internal layered design — API facade layer, business layer, persistence layer — or sub-domain partitioning. The API access facade internally orchestrates the business request: class-level orchestration rather than external service orchestration.
• ACID vs BASE: coarse-grained services preserve ACID commit and rollback within a service. The book states that service-based architecture preserves ACID transactions better than any other distributed architecture.
• Database partitioning: putting entity objects in a single shared library is “the least effective way” of implementing this style; instead, logically partition the database into domains and mirror them as federated shared libraries, with a common_entities_lib locked in version control under database-team control.
• Orchestration vs choreography are defined here: orchestration coordinates via a separate mediator service — “like a conductor in an orchestra”; choreography has services talk to each other with no central mediator — “like dancers in a dance”. Because services are coarse-grained, this style needs them much less, and no orchestrator is required. Interservice communication between domain services is “something to definitely avoid”.

Ratings stated in prose: “service-based architecture does not contain any five-star ratings” — agility 4, testability 4, deployability 4, fault tolerance/availability 4, scalability 3, elasticity 2. Partitioning: domain. Quanta: at least one — 4 to 12 services sharing one database and one UI is a single quantum; federating the UI and the database yields more.

When to use: when you want architectural modularity, agility and deployability without the cost, complexity and granularity pitfalls of microservices; a natural fit for domain-driven design; and the best distributed choice when you must preserve ACID transactions. When not: when you need fine-grained independent scaling and elasticity, or when domain services would have to call each other frequently.

A popular distributed asynchronous style made of decoupled event processing components that asynchronously receive and process events. It can be used standalone or embedded in another style. It is contrasted with the request-based model (a request orchestrator dispatching to request processors, deterministic and synchronous) — the event-based model instead reacts to a situation.

Broker topology

No central mediator: message flow is distributed across event processors “in a chain-like broadcasting fashion” through a lightweight broker such as RabbitMQ, ActiveMQ or HornetQ. Four components: initiating event, event broker, event processor, processing event. Each processor does its task and then advertises what it did as a new processing event. Brokers are usually federated — domain-based clustered instances — and use topics with publish-and-subscribe. The book’s analogy: a relay race.

Advantages: highly decoupled event processors, high scalability, high responsiveness, high performance, high fault tolerance. Disadvantages: workflow control, error handling, recoverability, restart capabilities, data inconsistency.

Mediator topology

Components: initiating event, event queue, event mediator, event channels, event processors. The initiating event goes to an initiating event queue; the mediator knows the workflow steps and generates processing events onto dedicated event channels — usually queues, point-to-point. Processors do not advertise to the rest of the system: they report back to the mediator. Usually there are multiple mediators, one per domain.

Implementation tiers: simple mediators (Apache Camel, Mule ESB, Spring Integration) → BPEL engines (Apache ODE, Oracle BPEL Process Manager) for complex conditional workflows → BPM engines (jBPM) for long-running workflows with human intervention. The recommended mediator delegation model classifies events as simple, hard or complex and routes every event through a simple mediator that forwards on.

A precise terminological point: occurrences in the mediator topology are commands (must be processed); occurrences in the broker topology are events (can be ignored).

Advantages: workflow control, error handling, recoverability, restart capabilities, better data consistency. Disadvantages: more coupling of event processors, lower scalability, lower performance, lower fault tolerance, modelling complex workflows.

Named mechanisms

• Workflow event pattern for error handling — delegation, containment and repair: the consumer immediately delegates the error to a workflow delegate and moves on; the delegate repairs the message programmatically and resubmits it to the original queue, or forwards it to a dashboard for manual fixing. Consequence: repaired messages are reprocessed out of sequence.
• Preventing data loss — three loss points and their fixes: (1) the message never reaches the queue → persistent message queues (guaranteed delivery) plus synchronous send; (2) the consumer crashes after dequeuing → client acknowledge mode rather than the default auto acknowledge mode; (3) the consumer cannot persist → ACID transaction plus last participant support (LPS).
• Request-reply, pseudosynchronous: each channel is a request queue plus a reply queue, matched either by a correlation ID with a message selector (recommended) or by a temporary queue.
• Broadcast capabilities give the highest level of decoupling and are the basis for eventual-consistency patterns and complex event processing (CEP).
• Hybrids: event-driven microservices, event-driven space-based, event-driven microkernel, event-driven pipeline.

Ratings stated in prose: performance 5, scalability 5, fault tolerance 5, evolutionary 5 stars; simplicity and testability rate relatively low. Partitioning: primarily technical — a domain is spread across many processors, mediators, queues and topics. Quanta: one to many — processors sharing a single database instance fall in the same quantum, and request-reply ties processors into the same quantum even though communication is asynchronous.

When to use: choose the event-based model for flexible, action-based events requiring high responsiveness and scale with complex dynamic user processing; choose request-based for well-structured, data-driven requests where certainty and control over the workflow are needed. Within EDA: broker for high responsiveness and simple flows, mediator when you need workflow control, error handling and recoverability.

Named after tuple space — multiple parallel processors communicating through shared memory. It removes the central database as a synchronous constraint and instead uses replicated in-memory data grids: application data is held in memory and replicated among all active processing units, with updates sent asynchronously to the database, usually via messaging with persistent queues. Processing units start and stop dynamically with load.

The motivation is the “triangle-shaped” scalability limit of the classic web → app → database topology, where the database is the final limiting factor.

The five components

• Processing unit — the application logic (web components plus backend business logic, and possibly small single-purpose services), plus an in-memory data grid and a replication engine (Hazelcast, Apache Ignite, Oracle Coherence).
• Virtualized middleware, with four sub-components:
  • Messaging grid — manages input request and session state, deciding which processing unit receives a request (round-robin to the next available). Usually a load-balancing web server such as HAProxy or Nginx.
  • Data grid — “perhaps the most important and crucial component”. In modern implementations it lives inside the processing units as a replicated cache. Synchronisation between processing units sharing the same named cache is asynchronous, usually under 100 ms; each unit tracks the others through a member list of IPs and ports.
  • Processing grid — optional; orchestrates a request that spans multiple processing unit types, e.g. order plus payment.
  • Deployment manager — manages dynamic start-up and shutdown of processing unit instances based on response times and user load; critical to achieving variable scalability, i.e. elasticity.
• Data pumps — always asynchronous, usually messaging with guaranteed delivery and FIFO ordering. The processing unit that updated its cache becomes the owner of the update and is responsible for pumping it out. Usually one pump per domain or per cache type; pumps carry contracts including an action (add, delete, update).
• Data writers — consume data pump messages and update the database. Either domain-based (one writer for all pumps in a domain) or dedicated per processing-unit class.
• Data readers — read from the database and feed processing units through a reverse data pump. Invoked in only three situations: a crash of all instances of the same named cache, a redeployment of all those instances, or retrieval of archive data not in cache. Start-up uses a cache lock: the first instance to grab it becomes temporary cache owner, requests the data, loads the cache and releases the lock.

Readers and writers together form a data abstraction layer — processing units decoupled from the database schema via separate contracts, with transformation logic in the readers and writers — rather than a data access layer, which would be coupled to the underlying structures.

Replicated vs distributed caching: a replicated cache optimises performance, suits a small cache (<100 MB) of relatively static data with a low update frequency, and gives high fault tolerance; a distributed cache optimises consistency, suits a large cache (>500 MB) of highly dynamic data with a high update rate, and has low fault tolerance. Replicated caching is the standard model here and has no single point of failure. The hybrid near-cache — distributed cache as full backing cache, each in-memory grid as front cache, with an eviction policy (MRU, MFU or random replacement) — is explicitly not recommended for this style, because front caches sync to the backing cache but not to each other. Note also the risk of data collisions in active/active replicated caching, due to replication latency.

Ratings stated in prose: elasticity 5, scalability 5, performance 5, testability 1 star. It is called “a very complicated architecture style” and “relatively expensive”. Partitioning: both domain and technical. Quanta: vary, delineated by the association between user interfaces and processing units — and note that the database is not part of the quantum equation, because processing units never talk to it synchronously.

When to use: applications experiencing high spikes in user or request volume, and applications with throughput in excess of 10,000 concurrent users. Canonical examples: online concert ticketing systems, where volume jumps from hundreds to tens of thousands the moment tickets go on sale, and online auction systems, where one processing unit per auction ensures bidding consistency. When not: when you cannot tolerate the complexity, the eventual consistency of the system of record, the cost, or the near-impossibility of realistic load testing outside production.

A distributed architecture from the late 1990s enterprise era, driven by scarce and expensive compute, per-machine OS licences and Byzantine database licensing — so enterprise-level reuse became the dominant philosophy. It establishes a taxonomy of services, each layer with a specific responsibility, all wired through a central orchestration engine or service bus.

Service type	Responsibility
Business services	The entry point at the top: domain behaviour such as ExecuteTrade or PlaceOrder. Litmus test: can you answer “are we in the business of…?” affirmatively. These definitions contain no code — just input, output, sometimes schema; they are defined by business users
Enterprise services	Fine-grained, shared implementations built by developers: CreateCustomer, CalculateQuote. The reusable building blocks composing the coarse-grained business services
Application services	One-off, single-implementation services not needing reuse — e.g. geolocation for one application; owned by a single application team
Infrastructure services	Operational concerns: monitoring, logging, authentication, authorization; owned by a shared infrastructure team
Orchestration engine	“The heart of this distributed architecture”: stitches business services together, handles transactional coordination and message transformation declaratively, defines service relationships and transaction boundaries, and acts as an integration hub. Tied to a single or few relational databases, not database-per-service

All requests go through the engine, even internal calls: the service bus is the intermediary for everything.

The reuse trap. Aggressive reuse — extracting a canonical Customer service across insurance divisions — produced huge coupling: a change to Customer rippled to all consumers, forcing coordinated deployments and holistic testing. Second, the single canonical Customer had to carry every attribute any division needed. Third and most damaging, extreme technical partitioning meant a domain concept such as CatalogCheckout was “spread so thinly throughout this architecture that it was virtually ground to dust”: adding one address line could touch dozens of services across several tiers, plus a schema change.

Ratings: no numeric values survive in the extracted text. In prose: deployability and testability “score disastrously”; elasticity and scalability were supported despite the difficulties; performance “was never a highlight… and was extremely poor because each business request was split across so much of the architecture”; simplicity and cost “have the inverse relationship most architects would prefer”. Partitioning: perhaps the most technically partitioned general-purpose architecture ever attempted. Quantum: a single quantum despite being distributed, because of the one-or-few databases and because the orchestration engine is a giant coupling point — no part of the architecture can have different architecture characteristics than the mediator that orchestrates all behaviour.

Named early and popularised by Martin Fowler and James Lewis in their March 2014 blog post. Each service runs in its own process — physical machine, then VM, then container — and architects expect each service to include all necessary parts to operate independently, including databases and other dependent components. Service size is much smaller than in orchestration-driven SOA. An optional API layer sits between consumers and services. The whole style is the physical embodiment of the bounded context.

• Bounded context — each service models a domain or workflow; internals (code, data schemas) are coupled inside and never coupled to anything outside. “Microservices take the concept of a domain-partitioned architecture to the extreme.” Corollary: prefer duplication to coupling — if the goal requires high degrees of decoupling, favour duplication over reuse.
• Granularity — the hardest problem. “The term microservice is a label, not a description” (Fowler). Three guidelines for finding boundaries: purpose (extreme functional cohesion, one significant behaviour), transactions (entities that must cooperate in a transaction often mark a boundary), choreography (if services need extensive communication, bundle them back into a larger service). Iteration is the only way to ensure good service design.
• Data isolation — no shared schemas, no database as integration point; beware the entity trap. You must choose a single domain as source of truth for a fact, or use replication and caching. The upside: each service picks the most appropriate database.
• API layer — optional, good for indirection and for tying into operational facilities such as a naming service. It must not be used as a mediator or orchestration tool: all interesting logic should occur inside a bounded context.
• Operational reuse — microservices splits domain reuse (avoided) from operational reuse (embraced). The sidecar pattern places common operational concerns — monitoring, logging, circuit breakers — in a separate component inside each service, owned by a shared infrastructure team, so upgrades propagate centrally. Connected sidecars form a service mesh wired into a service plane, giving holistic global control of operational coupling. Service discovery builds elasticity: requests route through a discovery tool that can monitor request volume and spin up new instances.
• Frontends — the original vision put the UI inside the bounded context, but web constraints make that hard, so two styles exist: a monolithic frontend calling through the API layer, or microfrontends, where each service emits its own UI component and a single team owns the domain from UI to backend.
• Communication — synchronous microservices use protocol-aware heterogeneous interoperability: protocol-aware because there is no central integration hub, so each service must know or discover which protocol to use; heterogeneous because of full polyglot support; interoperability because services call one another over the network. Asynchronous communication uses events and messages, i.e. an embedded event-driven architecture — the broker and mediator patterns manifest in microservices as choreography and orchestration.
• Transactions and sagas — “do not do transactions in microservices, fix granularity instead”. Cross-service transactions create connascence of value, “the worst kind of dynamic connascence”. Where unavoidable, the saga pattern uses a mediator that calls each part, records success or failure, and on error triggers a compensating transaction framework. Use it sparingly: “if it is the dominant feature of the architecture, mistakes were made”.

Ratings: no explicit star numbers survive. In prose: the high points are scalability, elasticity and evolutionary; high support for automated deployment and testability; fault tolerance gets a high rating under normal circumstances thanks to independent single-purpose services, though fault tolerance and reliability are impacted when too much interservice communication is used; performance is often an issue, because of network calls plus per-endpoint security checks. Partitioning: decidedly domain-centred. Quanta: the most distinct quanta of any modern architecture — in many ways it exemplifies what the quantum measure evaluates.

When to use: where decoupling, independent evolution, scalability and elasticity dominate, and where DevOps automation exists — “microservices could not exist without the DevOps revolution”. When not: where performance is paramount (many network hops), where you cannot avoid cross-service transactions, or where you would be forced to make services so small that you rebuild the communication links between them.