TL;DR

Modular Monolith là kiến trúc kết hợp tính đơn giản của monolith truyền thống (triển khai single unit) với tính modular của microservices. Ứng dụng được chia thành các module độc lập, loosely coupled, có ranh giới rõ ràng (clear boundaries), nhưng vẫn chạy trong cùng một process. Các công ty như Shopify (30TB/min), GitHub (repositories module), Basecamp, Zendesk đã chứng minh khả năng scalability. Phù hợp nhất cho startups/growing teams, legacy system modernization, và projects dự tính sẽ cần microservices trong tương lai.

Khái Niệm Cơ Bản

Một modular monolith tổ chức ứng dụng thành các module độc lập, mỗi module chịu trách nhiệm một business domain cụ thể (ví dụ: Authentication, Orders, Payments, Inventory). Thay vì những component bị tightly tangled (như traditional monolith), mỗi module có:

  • Clear boundaries - ranh giới rõ ràng giữa các module
  • Isolated data - mỗi module quản lý data riêng (tối thiểu là schema riêng trong database)
  • Well-defined interfaces - giao tiếp qua contracts, APIs hoặc events
  • Single deployment unit - toàn bộ vẫn triển khai như một ứng dụng duy nhất

Ví dụ, Shopify tổ chức monolith thành modules như "Orders" và "Payments", mỗi module có public API riêng và isolated database, nhưng chúng vẫn cùng deployed.

So Sánh Với Kiến Trúc Khác

So sánh kiến trúc

vs Traditional Monolith

  • Traditional: Tất cả components tightly intertwined, một thay đổi ở component A có thể gây cascading failure ở B. Khó scale, khó maintain khi codebase lớn.
  • Modular Monolith: Enforce separation of concerns, clear boundaries giữa modules, phòng chống tight coupling. Dễ debug, maintain, refactor.

vs Microservices

Microservices lợi: Independence, polyglot stacks, per-service scaling.
Microservices phạt: Distributed systems complexity (network latency, eventual consistency, service discovery, API gateways, multiple deployments).

Modular Monolith lợi: Simplified deployment (single unit), in-process communication (no network overhead), ACID transactions, lower operational cost.
Modular Monolith phạt: Limited independent scaling (phải scale toàn app), shared runtime risks (memory leak ở 1 module → crash toàn system).

Lợi Ích Chính

  • Simple Deployment - chỉ deploy một unit, không phức tạp như orchestrating multiple services
  • Fast In-Process Communication - modules gọi nhau qua method calls hoặc events (in-memory), không network overhead
  • Transactional Consistency - dễ dàng implement ACID transactions giữa modules, không distributed transaction nightmare
  • Lower Operational Overhead - ít infrastructure để manage, không cần service discovery, API gateway, distributed logging
  • Easier Debugging - toàn bộ stack trace ở một process, dễ diagnose issues
  • Parallel Team Development - multiple teams có thể work trên các modules khác nhau mà không xung đột
  • Evolutionary Path - khi scaling demand thực sự arise, dễ dàng extract high-demand module thành microservice (modules đã có clear boundaries + isolated data từ đầu)

Hạn Chế và Trade-offs

  • Limited Independent Scaling - không scale single module riêng lẻ, phải scale toàn app (limitation so với microservices)
  • Shared Runtime Risks - memory leak hoặc crash ở 1 module → cascading failure toàn hệ (thách thức so với monolithic simplicity)
  • Data Querying Complexity - module isolation cấm SQL JOINs across modules. Phải dùng API calls, caching, hoặc data duplication → performance overhead nếu không quản lý cẩn thận
  • Dependency Management Overhead - cần discipline mạnh để tránh tight coupling giữa modules, không tự động enforce như physical service boundaries

Ứng Dụng Thực Tế

Real-world examples

  • Shopify - e-commerce platform, xử lý 30TB/minute, modularized thành Orders + Payments với isolated databases
  • GitHub - version control, organize thành modules cho repositories, pull requests, issues
  • Basecamp - project management, features tách riêng: tasks, messages, calendars
  • Zendesk - customer support, modular cho tickets, chat, knowledge base

Khi Nào Nên Dùng

Module boundaries

Modular Monolith phù hợp nhất khi:

  • Startups/Small Teams - chưa xác định product scope rõ ràng hoặc không cần scale millions users ngay → move quickly mà không Docker overhead
  • Growing Engineering Organizations - domain phức tạp nhưng có clear functional boundaries → multiple teams làm việc song song
  • Modernizing Legacy Systems - transform "big ball of mud" monolith thành structured modules, preparing for future evolution
  • Projects Anticipating Future Microservices - biết sẽ cần microservices sau, nhưng chưa cần ngay → modular monolith as stepping stone

KHÔNG nên dùng khi:

  • Cần scale individual components independently (ví dụ: payment service phải handle 100x traffic so với orders) → microservices là better fit
  • Teams completely autonomous, không muốn share codebase → polyglot microservices setup
  • Single component failure không thể tolerant (mission-critical system, bank) → need bulletproof isolation

Kỹ Thuật Triển Khai

Module Boundaries Principles

  • Domain-Driven Design (DDD) - organize modules around business domains (Bounded Contexts)
  • Clear API Contracts - mỗi module expose public interface, hide internal implementation
  • Data Isolation - BEST PRACTICE: mỗi module manage riêng data (separate schema hoặc database)
  • Unidirectional Dependencies - A → B OK, nhưng B → A = forbidden (prevent circular coupling)

Communication Patterns

  • Integration Services - module A gọi method của module B qua service interface (chỉ read-only, caching nếu frequent)
  • Integration Events - module A publish event, module B subscribe + react (loose coupling, ready cho distributed transition khi migrate sang microservices)
  • Shared Kernel - common utilities, configs, logging (nhưng cẩn thận: không để business logic rò rỉ vào shared kernel)

Frameworks & Tools

Các framework hỗ trợ modular monoliths:

  • ASP.NET Core (.NET) + ABP Platform (open-source, pre-built modules)
  • Spring Boot (Java) - dependency injection, modular routing
  • Django (Python) - reusable apps, middleware, naturally modular
  • Laravel (PHP) - routing, middleware, Eloquent ORM
  • Ruby on Rails - MVC, convention over configuration

Con Số Bạn Nên Biết

  • Shopify: 30TB/minute peak throughput (Black Friday scale)
  • Production System: 50+ use cases, dozens API endpoints = ~6,000 lines of code
  • ABP Platform: Running v10.7.0-preview on .NET 10.0.9
  • Milan Jovanović's Course: $297 basic / $497 community edition, 12-14+ hours video, lifetime access

Kết

Modular Monolith đại diện cho giải pháp pragmatic giữa simplicity của monolith truyền thống và flexibility của microservices. Nó không phải silver bullet — có trade-offs rõ ràng (limited independent scaling, shared runtime risks) — nhưng với teams biết manage boundaries + discipline, architecture này mang lại "sweet spot" giữa deployment simplicity, development velocity, và operational efficiency.

Bắt đầu với monolithic mindset + modular structure. Khi scaling demands thực sự arise, extraction path đã sẵn sàng. Như Shopify chứng minh: "start monolithic, evolve when necessary."

Nên học thêm: via Milan Jovanović's Modular Monolith course, via ABP Platform Architecture, via Modular Monoliths official site.