The industry spent a decade telling everyone to build microservices. Then everyone who did it at small scale discovered they'd bought a distributed-systems problem to solve a code-organization problem. There's a saner middle path, and it's what I built DineGuru on: the modular monolith.
The false choice
The debate is usually framed as monolith vs microservices, as if you must pick a big ball of mud or a constellation of networked services. Both extremes have real costs:
- A tangled monolith has no internal boundaries — everything reaches into everything, and it rots.
- Microservices give you boundaries, but at the price of network calls, distributed transactions, deployment complexity, and debugging across process lines — an enormous tax to pay before you have the scale that justifies it.
For a product that needs clean separation but not planet-scale, both are wrong.
The middle path
DineGuru is a FastAPI modular monolith over PostgreSQL with nine clear domain modules — identity and access, menu catalog, ingredient stock, orders and billing, recipe costing, procurement, analytics, and more. It ships and runs as one application, but internally it's organized into well-bounded domains with real separation of concerns.
You get the best of both:
- The boundaries of services — each domain is a coherent module with a clear responsibility, so the codebase stays navigable and changes stay local.
- Without the distributed tax — no network hops between domains, no distributed transactions, one thing to deploy and debug. The separation lives in the code, not spread across a network.
And crucially, it's a path you can grow along. Well-defined module boundaries are exactly what make it possible to later extract a genuine service if and when a domain earns it — you've done the hard part (drawing the lines) up front, cheaply.
The lesson
Architecture should match your actual scale and constraints, not the conference-talk fashion of the year. A modular monolith gives a product like DineGuru the maintainability of good separation without paying for distributed complexity it doesn't need yet. Start with clear boundaries in one deployable unit; distribute later, only where reality demands it.
The full architecture is on the project page.
👉 See the platform: www.divyakush.com/projects/dineguru
Divyakush Punjabi — Full-Stack & AI Systems Engineer
🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub
Top comments (0)