From Monolith to Microservices: A Practical Guide to Architecture Evolution

III. Architecture Levels

We use a pyramid model to illustrate that higher levels contain the lower ones.

System level : relationships and governance across the whole system, including layering.

Application level : overall architecture of a single application and its relation to other applications within the system.

Module level : internal module architecture of an application, such as code modularization and state management.

Code level : ensuring architectural implementation at the code level.

Strategic vs. Tactical Design

Based on the architecture pyramid, strategic design (business architecture) guides architects, while tactical design (application architecture) follows the business architecture, and tactical implementation selects technology.

IV. Application Architecture Evolution

Business architecture is productivity, application architecture defines production relationships, and technology architecture provides the tools. Business architecture determines application architecture, which must adapt and evolve with it, ultimately realized through technology architecture.

Evolution path: Monolith → Distributed Services → Micro‑services

4.1 Monolith

When a business is simple, a monolithic application handling basic CRUD operations suffices. Typical three‑tier architecture (frontend, middle‑business logic, database) exemplified by Java Spring MVC or Python Django.

Non‑functional measures for monoliths include caching for performance, clustering for concurrency, read/write separation, reverse proxy/CDN acceleration, and distributed files/databases.

High complexity: large codebase, unclear module boundaries, tangled dependencies.

Technical debt accumulation over time.

Low deployment frequency due to full‑stack redeployment.

Poor reliability: a single bug can crash the whole system.

Limited scalability: cannot scale individual modules independently.

Hinders innovation: uniform tech stack makes adopting new technologies difficult.

4.2 Distributed

As business functions grow, monoliths become unwieldy, prompting decomposition into services deployed on separate servers communicating via interfaces.

Advantages:

Reduced coupling through interface‑based communication.

Clear responsibilities across sub‑projects.

Easy extensibility by adding new services.

Flexible deployment of distributed components.

Improved code reuse, e.g., shared service layers across web, mobile, and other clients.

Drawback: increased remote communication overhead.

4.3 Micro‑services

When business logic becomes highly complex (pricing, promotions, multi‑channel sales), a micro‑kernel service architecture is needed to centralize rules.

Characteristics:

Easy development and maintenance: each service focuses on a single business capability.

Fast startup due to small codebase.

Localized deployment: only the modified service needs redeployment.

Technology‑agnostic: different services can use different stacks (MySQL, Neo4j, Java, Node.js, etc.).

Challenges (costs):

Higher operational overhead to keep many services running.

Inherent distributed complexity (fault tolerance, latency, transactions).

API change impact across dependent services.

Potential duplicate effort when common functionality is not abstracted into shared services.

V. Measuring Architecture Rationality

There is no universally optimal architecture, only the most suitable one, judged by efficiency, stability, and security.

5.1 Business‑Driven Criteria

Solves current business needs.

Delivers solutions efficiently and reusable.

Forward‑looking design that remains viable as business evolves.

5.2 Non‑Business Criteria

Stability : high availability achieved through testing, automation, and fault injection.

Efficiency :

Comprehensive documentation throughout the lifecycle.

Scalability via low‑coupling and proper abstraction.

High reusability to avoid duplicated effort and reduce cost.

Security : protect valuable data with encryption, HTTPS, and other standard measures.