Modular monolith and microservices: Modularity is what matters

Original Article ↗ Hacker News Discussion ↗

Core Theme: Modularity Over Architecture Labels

  • Broad agreement that modularity, not “monolith vs microservices,” is the key design concern.
  • Good modularity means clear domains, explicit contracts/APIs, clean dependency trees, and the ability to evolve or extract pieces with minimal pain.
  • Several note you can have:
    • A single deployable that behaves like multiple services (different roles via config, different routes, horizontal scaling per endpoint).
    • Many deployables that are effectively a tightly coupled monolith due to unmanaged API changes.

Enforcing Modularity

  • Main challenge is not the idea but enforcement over time and headcount.
  • Three approaches discussed:
    • Social/”architect as gatekeeper” – works only for small teams.
    • Education/culture – tends to drift.
    • Tooling – e.g., multi-module builds that forbid forbidden imports; language ecosystems differ here.
  • Strong top‑down direction (from CTO/executives) is seen as necessary to keep modularity and avoid microservices-by-default.

Microservices: Benefits and Costs

  • Pros cited:
    • Network boundaries force people to think about contracts, data passed, and backwards compatibility.
    • Independent deployability and dependency upgrades; each service can move at its own pace.
    • Organizational scaling: teams own services, align with Conway’s law, and can be staffed/operated independently.
    • Isolation of failures and scaling hotspots (e.g., video encoding, high‑traffic endpoints).
  • Cons cited:
    • Explosion of services (“nano-services”), more teams, more tooling, more operational and security surface.
    • Debugging and development friction when many services must be running; hard local setups.
    • Versioning pain at boundaries; breaking API changes become much harder.
    • Often misused for low‑traffic, low‑complexity systems where a monolith would suffice.

Monoliths & Modular Monoliths

  • Many argue 99%+ of apps are better off starting as a monolith, scaled vertically and then horizontally as needed.
  • Modular monolith strategies: vertical slices by feature, shared libraries, environment‑driven role selection, separate deployments of the same codebase.
  • Good monoliths can handle substantial scale and are easier to reason about, debug, and refactor.
  • Pathology cases (giant, outdated monoliths with huge startup time and tech debt) are blamed on deferred maintenance and poor tooling, not on monoliths per se.

Nuance & Spectrum

  • Multiple commenters frame this as a spectrum: from a single, well‑structured deployable; to a few coarse‑grained services; to hyper‑granular microservices.
  • Consensus trend: start simple and modular, split into services only where scale, organizational structure, or security/data‑isolation clearly justify the added complexity.