Definition
- Monolith – one deployable unit; solves simplicity.
- Modular Monolith – one deployable with enforced module boundaries; solves maintainability without distribution.
- Microservices – independently deployable services; solves independent scaling and team autonomy at the cost of distributed complexity.
- Layered (N-Tier) – horizontal layers (controller, service, repository); solves separation of concerns.
- Microkernel/Plugin – stable core plus plugins; solves extensibility.
- Hexagonal (Ports and Adapters) – domain in the center with technology-agnostic ports; solves testability and technology independence.
- Space-Based – in-memory data grid; solves extreme bursty load by removing the database bottleneck.
- Peer-to-Peer – no central coordinator; solves decentralization (blockchain, mesh).
Think of National Bank of India as a building. A Monolith is one big open-plan office. A Modular Monolith is the same building with walled departments. Microservices are separate buildings across the city. Layered is one building with floors. Microkernel is a core with pluggable product modules. Hexagonal is a department designed so it does not care whether customers arrive by phone, web, or in person. Space-Based is a trading floor keeping everything in fast memory. Peer-to-Peer is a network of branches that gossip directly with no head office.
Understanding the Concepts
What is a Monolith?
One deployable artifact, one process. The problem it solves is simplicity: one codebase, one build, one deploy, in-process calls, easy transactions. Right default for small teams and early products.
// Monolith: all features in one deployable
package com.bank;
@SpringBootApplication
public class BankApplication {
// Transfers, Accounts, Fraud, Notifications all here
}
What is a Modular Monolith?
Still one deployable, but internally split into modules with enforced boundaries. Solves maintainability and future-proofing. Recommended starting point before microservices.
// Modular Monolith: clear module interfaces
package com.bank.transfers;
public interface TransferModule {
Transfer execute(String fromId, String toId, BigDecimal amount);
}
package com.bank.accounts;
public interface AccountModule {
BigDecimal getBalance(String accountId);
}
// Modules interact through interfaces, not by reaching into internals
What are Microservices?
Many small, independently deployable services, each owning its own data. Solves independent deployment, scaling, and team autonomy. Cost: distributed complexity.
How do Layered, Microkernel, and Hexagonal fit?
These are code-organization styles that live INSIDE a deployable, not alternatives to a deployment choice.
| Style | Axis | Problem Solved |
|---|---|---|
| Monolith | Deployment | Simplicity |
| Modular Monolith | Deployment | Maintainability |
| Microservices | Deployment | Independence |
| Layered | Code organization | Separation of concerns |
| Microkernel | Code organization | Extensibility |
| Hexagonal | Code organization | Testability, tech independence |
| Space-Based | Data architecture | Extreme load |
| Peer-to-Peer | Network topology | Decentralization |
When should you use each?
// WRONG: reaching for microservices because they are trendy
// A 3-person team building an MVP does not need 15 services.
// CORRECT: match the style to the problem
if (smallTeam && earlyProduct) use(MONOLITH);
else if (multipleteams && needIndependence) use(MICROSERVICES);
// Apply hexagonal INSIDE each service for testability
What is Space-Based architecture?
Keeps state in an in-memory data grid replicated across nodes, removing the database bottleneck under extreme bursty load. Used for trading systems and flash sales.
What is Peer-to-Peer?
No central coordinator; every node is both client and server. Solves decentralization (blockchain, file sharing, mesh networks).
Are these styles mutually exclusive?
No. A real banking platform is often microservices (deployment), where each service is internally hexagonal (code organization), one service is a microkernel product engine, a hot trading path is space-based, and an inter-bank settlement is peer-to-peer.
What should a senior engineer know?
- The classic mistake is adopting microservices for resume value when a modular monolith would serve better.
- Start simple, split only when a real need arises.
- Choosing a style is choosing which problem to prioritize.
- You combine styles across deployment and code-organization dimensions.
Visual Overview
Architecture Styles Comparison
Deployment Axis:
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ Monolith │ │ Modular Monolith │ │ Microservices │
│ ┌──────────────┐ │ │ ┌──────┐ ┌──────┐ │ │ ┌────┐ ┌────┐ │
│ │ All features │ │ │ │ Mod-A│ │ Mod-B│ │ │ │Svc1│ │Svc2│ │
│ │ one process │ │ │ │ │ │ │ │ │ │own │ │own │ │
│ └──────────────┘ │ │ └──────┘ └──────┘ │ │ │ DB │ │ DB │ │
│ 1 deploy │ │ 1 deploy, walls │ │ └────┘ └────┘ │
└────────────────────┘ └────────────────────┘ │ N deploys │
└────────────────────┘
Code Organization Axis (inside one deployable):
┌────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Layered │ │ Microkernel │ │ Hexagonal │
│ Controller │ │ Core │ │ ┌──────────┐ │
│ Service │ │ ┌───┐ ┌───┐ │ │ │ Domain │ │
│ Repository │ │ │Pl1│ │Pl2│ │ │ │ (pure) │ │
│ Database │ │ └───┘ └───┘ │ │ └──────────┘ │
└────────────┘ └──────────────┘ │ Ports + Adapters │
└──────────────────┘
Key Takeaway
Architecture styles each solve one dominant problem, and the skill is matching the style to the problem. A monolith solves simplicity and is the right default for a small team. A modular monolith keeps that simplicity but enforces internal boundaries, and is the recommended starting point. Microservices solve independent deployment and team autonomy, but cost distributed complexity that only pays off with multiple teams needing independence.
The code-organization styles -- layered, microkernel, hexagonal -- live inside a deployable, not instead of one. A real banking platform combines several: microservices for deployment, hexagonal inside each service for testability, a microkernel product engine, and a space-based hot trading path.
At National Bank of India, Pankaj started with a modular monolith, extracted only the fraud service when it needed independent scaling, and applied hexagonal architecture inside each service. The classic mistake is reaching for microservices because they look impressive when a modular monolith solves the actual problem with far less pain.
Remember one sentence: every architecture style exists to solve one specific problem, so pick the style whose problem matches yours and combine styles across deployment and code-organization dimensions.
---