Software Architecture Styles + Lambda Architecture

---
config:
  theme: neutral
  fontSize: 16
---
flowchart TD
    S["Architecture styles"]:::gov
    S --> L["Layered"]:::obs
    S --> ED["Event-driven"]:::server
    S --> MK["Micro-kernel / plugin"]:::gate
    S --> MS["Microservices"]:::good
    S --> MA["Macroservices"]:::good
    S --> SB["Space-based"]:::warn
    S --> SOA["SOA"]:::obs
    classDef gov fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef obs fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef server fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111
    classDef gate fill:#DCDCDC,stroke:#333333,stroke-width:1px,color:#111111
    classDef good fill:#E8E8E8,stroke:#333333,stroke-width:1px,color:#111111
    classDef warn fill:#C0C0C0,stroke:#333333,stroke-width:1px,color:#111111

Figure 1: The menu of architecture styles each is a high-level shape with its own strengths and trade-offs.

Before you design components, you choose a shape an architecture style that determines how the big pieces relate. And every style is a bundle of trade-offs: layered is simple but can be rigid; microservices scale teams but add operational weight; event-driven decouples but goes eventually-consistent. The mistake isn’t picking the “wrong” style it’s picking one by default without knowing what you traded away. Here’s the menu, how to choose from it, and a closer look at one big-data workhorse: the Lambda Architecture.

Summary

• A style is a high-level shape with inherent trade-offs. Pick it deliberately against your constraints, not by habit.
• Common styles: Layered, Event-driven, Micro-kernel (plugin), Microservices, Macroservices, Space-based, and SOA each optimizes different things.
• Choose by your real constraints team structure, scale, consistency needs, deployment independence not by what’s fashionable.
• Lambda Architecture processes big data with three layers batch (accurate, slow), speed (fast, approximate), and serving (merges both) to get both completeness and low latency.
• Styles compose. Real systems blend them (microservices that are internally layered and communicate via events).

1. The common styles, and what each optimizes

A handful of styles cover most systems, and the useful thing is to know what each one is good at:

• Layered organize into layers, each closer to the machine (UI → app logic → utilities → OS interface). The familiar default (TCP/IP is layered). Simple and well-understood; can become rigid and tempt you into a “big ball of mud” if layers leak.
• Event-driven components communicate through events; a state change emits an event others react to. Excellent decoupling and resilience; the cost is eventual consistency and harder debugging.
• Micro-kernel (plugin) a minimal core plus independent plugins that implement shared interfaces (VS Code, Eclipse). Great when you need extensibility without touching the core.
• Microservices decompose a large system into independently-deployable services communicating via RPC. Scales teams and deployment, at real operational and distributed-systems cost.
• Macroservices the deliberate middle between monolith and microservices: a handful of coarse-grained services split along business domains, each big enough to own a whole capability (and sometimes to share a database). You get independent deploys per domain team without the operational sprawl of fifty nanoservices most organizations that “did microservices right” actually landed here.
• Space-based named for “tuple space” (distributed shared memory): processing units share replicated in-memory data, with no central database bottleneck, and scale elastically. Built for extreme, spiky load. In-memory data grids are the working implementations GigaSpaces (the original tuple-space product), GridGain / Apache Ignite, Hazelcast, and Oracle Coherence; I dig into one of them in Apache Ignite / GridGain: In-Memory Data Grid Fundamentals.
• SOA service-oriented architecture, the enterprise predecessor to microservices, organizing capabilities as reusable services.

The pattern to notice: each style removes one bottleneck and accepts another. Layered removes complexity at the cost of flexibility; microservices remove team coupling at the cost of operational complexity; space-based removes the database bottleneck at the cost of memory/consistency management. Knowing the accepted cost is what makes the choice deliberate.

2. How to choose and why styles compose

There’s no “best” style, only the best fit for your constraints. A few decision drivers:

---
config:
  theme: neutral
  fontSize: 16
---
flowchart LR
    C1["One team,<br/>evolving domain"]:::c --> L["Layered /<br/>modular monolith"]:::s
    C2["Many teams,<br/>independent deploys"]:::c --> MS["Microservices"]:::s
    C3["Domain teams,<br/>without service sprawl"]:::c --> MA["Macroservices"]:::s
    C4["Third-party<br/>extensibility"]:::c --> MK["Micro-kernel"]:::s
    C5["Async decoupling,<br/>react to changes"]:::c --> ED["Event-driven"]:::s
    C6["Extreme,<br/>spiky elastic load"]:::c --> SB["Space-based"]:::s
    classDef c fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef s fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111

Figure 2: The decision map read your dominant constraint on the left, and the style that answers it on the right.

Let the dominant constraint decide and name the cost you’re accepting while you’re at it, because that’s the half of the decision everyone skips:

Two anti-patterns fall straight out of the table. Reaching for microservices when a layered monolith would do you pay the distributed-systems tax to solve a team-scaling problem you don’t have. And its mirror: splitting one domain across many nanoservices a change to a single business capability now touches five repos and three deploy pipelines, which is how teams end up backpedaling to macroservices and calling it a “consolidation initiative.”

See all of them in action, Walk through a typical e-commerce platform:

• at the system level it’s macroservices (orders, catalog, payments three domain services, not thirty);
• inside each service the code is layered (API → domain logic → persistence);
• between services, order events flow through an event-driven backbone (a placed order triggers inventory, fulfillment, and email without payments knowing any of them exist);
• and the storefront supports vendor integrations through a micro-kernel plugin API.

Four styles, one system, each solving the problem at its own altitude. Underneath sits a CAP-aware data choice per service (RDBMS choosing consistency for payments, NoSQL choosing availability for the catalog a partition only forces that trade during the partition).

The data side has its own composable building blocks from the same era: consistent hashing distributes data across nodes so that adding or removing a node reshuffles only its neighbors, not everything, and leader election (Bully, Paxos, Raft, ZAB) picks a coordinator in a leaderless cluster. Styles for the code, these for the data same vocabulary game, one level down.

3. A closer look: Lambda Architecture

For processing massive data (“Big Data”) where you need both completeness and low latency, Lambda Architecture is a classic hybrid that solves the problem of computing arbitrary functions over all your data fast. It splits processing into three layers:

---
config:
  theme: neutral
  fontSize: 16
---
flowchart LR
    DATA["Incoming data"]:::neutral --> BATCH["Batch layer<br/>all data, accurate, slow"]:::server
    DATA --> SPEED["Speed layer<br/>recent data, fast, approximate"]:::warn
    BATCH --> SERVE["Serving layer<br/>merges both  queries"]:::good
    SPEED --> SERVE
    classDef neutral fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef server fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef warn fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111
    classDef good fill:#DCDCDC,stroke:#333333,stroke-width:1px,color:#111111

Figure 3: Lambda Architecture a slow-but-accurate batch layer and a fast-but-approximate speed layer, merged by a serving layer.

• Batch layer processes all the data to produce accurate, comprehensive results. Correct, but slow (it reprocesses the full dataset).
• Speed layer processes only recent data in real time to fill the gap while the batch layer is still crunching. Fast, but approximate.
• Serving layer merges the batch and speed views so a query gets both the accurate historical picture and the up-to-the-second recent data.

The elegant idea is using two pipelines to get the best of both: the batch layer guarantees eventual correctness, the speed layer guarantees freshness, and the serving layer hides the seam. (Its successor, the Kappa architecture, argues you can simplify to a single streaming pipeline a worthwhile debate once you understand why Lambda exists.)

Why it matters: architecture decisions are the most expensive ones to reverse, because everything is built on the shape you choose. Treat styles as a menu of trade-offs, pick by your dominant constraint rather than fashion, expect to compose several, and reach for specialized patterns like Lambda only when the problem (massive data needing both accuracy and low latency) actually calls for it. The goal isn’t the “right” architecture it’s the one whose accepted costs you can live with.

References

• Software Architecture Patterns (O’Reilly) Mark Richards on the common styles and their trade-offs
• Lambda Architecture the batch/speed/serving model for big data
• Fundamentals of Software Architecture Richards & Ford on choosing and combining styles