[{"_1":2,"_91":-5,"_92":-5},"loaderData",{"_3":4,"_12":13},"routes/_layout",{"_5":6},"pages",[7],{"_8":9,"_10":11},"slug","about","title","About me","routes/blog/index",{"_14":15,"_69":70,"_71":70,"_72":38,"_73":74,"_90":70},"posts",[16],{"_8":17,"_18":19,"_43":44,"_45":46},"the-modular-monolith-a-practical-middle-ground-you","meta",{"_10":20,"_21":22,"_23":24,"_25":26,"_34":35,"_36":37,"_41":42},"The Modular Monolith: A Practical Middle Ground","description","When you can skip microservices and still get most of the structure from a modular monolith.","date","2025-12-03","keywords",[27,28,29,30,31,32,33],"modular monolith","software architecture","microservices","monolith","domain boundaries","module design","scalability","author","Denys Bashkatov","tags",[38,39,40],"Architecture","JavaScript","Node.js","social",true,"html","

In 2019, I had the chance to work in an extremely highly skilled team. At that time, the microservices hype was happening, and I remember that I was also very inspired and wished to decompose new projects right from the very beginning. However, the team that I was a part of did not want to start with microservices; collectively, we decided to start with a modular monolith.\nThere were two main reasons for this. We did not know yet the exact boundaries for each microservice in the beginning of the project, and to reshape such boundaries later, when they are already split into physical services, this is very painful. And our goal in that moment was only to bring some structure into the code, because the need for scaling was still far from us.\nYou don't need independent services initially; you just need clear boundaries and a design that will allow you to move modules into separate services later. A modular monolith gives you these boundaries without forcing you to build a distributed system. Consequently, you also avoid the long list of network problems that come with it, such as timeouts, retries, and half-committed writes across several services.

What it actually is

You have one application and you deploy it like one piece, you build it once and run it as one process. But inside, the code is split into modules which are loosely connected between each other. Every module keeps for itself a clear border and holds its internal logic private, so the other modules can not reach inside and touch it. They talk only through the contracts which you define, not through some shared globals that everybody can grab. And what is the most important, every module owns also its own data, even when all of it sits in the same one database.

The cost microservices add

Distributed systems just change one set of problems for another set, which is bigger and more expensive. Calls that before were in-process now go over the network, so they add latency. In addition you get many other things: distributed transactions, service discovery, load balancing, and a separate deployment pipeline for each service. The tracing also must cross the boundaries between the services. And there is the work with data consistency too, which is the part that people underestimate the most.

A modular monolith gives you the same organizational benefit, which means clear ownership and separated concerns, but you don't pay this operational cost.

There is a second benefit which is not so visible. A well-structured modular monolith is much easier to split into services later than a tangled one. So you get more time. You use this time in order to understand where the real boundaries are, before you fix them in production.

Project structure

Imagine that you build an e-commerce platform. Instead of one flat directory with controllers, services and models, you organize the code by domain:

src/\n├── modules/\n│   ├── catalog/\n│   │   ├── catalog.module.ts\n│   │   ├── catalog.service.ts\n│   │   ├── catalog.repository.ts\n│   │   └── catalog.types.ts\n│   ├── orders/\n│   │   ├── orders.module.ts\n│   │   ├── orders.service.ts\n│   │   ├── orders.repository.ts\n│   │   └── orders.types.ts\n│   ├── payments/\n│   │   ├── payments.module.ts\n│   │   ├── payments.service.ts\n│   │   ├── payments.repository.ts\n│   │   └── payments.types.ts\n│   └── users/\n│       ├── users.module.ts\n│       ├── users.service.ts\n│       ├── users.repository.ts\n│       └── users.types.ts\n├── shared/\n│   ├── events.ts\n│   └── types.ts\n└── app.ts

Each module exposes a public API and hides everything else from the outside. But the folder structure by itself enforces nothing. If nobody enforces a boundary, then it is not a boundary. So each module exports only the things which it wants to expose:

// modules/catalog/catalog.module.ts\n\n// ...imports and the wiring of the service, I cut it here\n\n// this object is the public API, nothing else leaves the module\nexport const catalogModule = {\n  getProduct: (id: string) => service.getProductById(id),\n  listProducts: (filters: ProductFilters) => service.listProducts(filters),\n  onProductUpdated: service.productUpdatedEvent,\n};\n\nexport type { Product, ProductFilters } from './catalog.types';

The orders module can call catalogModule.getProduct(), but it can not import CatalogRepository directly.

An ESLint rule blocks cross-module internal imports before they reach the review, so it catches the typical "I will just import the repository directly, it is faster" shortcut already in the pull request:

// eslint.config.js\nexport default [\n  {\n    rules: {\n      'no-restricted-imports': ['error', {\n        patterns: [\n          {\n            group: ['*/modules/*/!(*.module|*.types)'],\n            message: 'Import from the module file, not internal files.',\n          },\n        ],\n      }],\n    },\n  },\n];

How do the modules talk to each other

Modules still must somehow communicate between each other. For this exist two ways. The direct call you use when you need to get an answer back from the other module. The events you use when you only want to say to everybody that something happened, but you do not wait for an answer.

With the direct call one module asks the other module some question and waits until the answer comes:

// modules/orders/orders.service.ts\n\nimport { catalogModule } from '../catalog/catalog.module';\n\nclass OrdersService {\n  async createOrder(userId: string, productId: string, quantity: number) {\n    const product = await catalogModule.getProduct(productId);\n\n    if (!product) {\n      throw new Error(`Product ${productId} not found`);\n    }\n\n    return this.repository.create({\n      userId,\n      productId,\n      quantity,\n      totalPrice: product.price * quantity,\n    });\n  }\n}

With events a module sends a notification and does not know or care who is listening:

// shared/events.ts\n\ntype EventHandler<T> = (payload: T) => void | Promise<void>;\n\nexport class EventBus {\n  private handlers = new Map<string, EventHandler<any>[]>();\n\n  on<T>(event: string, handler: EventHandler<T>) {\n    const existing = this.handlers.get(event) || [];\n    this.handlers.set(event, [...existing, handler]);\n  }\n\n  async emit<T>(event: string, payload: T) {\n    const handlers = this.handlers.get(event) || [];\n    // the real bus also catches errors per handler, here I keep it minimal\n    await Promise.all(handlers.map((h) => h(payload)));\n  }\n}\n\nexport const eventBus = new EventBus();

// modules/orders/orders.service.ts\nimport { eventBus } from '../../shared/events';\n\n// After creating an order:\nawait eventBus.emit('order.created', { orderId, userId, productId, quantity });

// modules/payments/payments.module.ts\nimport { eventBus } from '../../shared/events';\nimport { PaymentsService } from './payments.service';\n\nconst service = new PaymentsService();\n\neventBus.on('order.created', async (order) => {\n  await service.initiatePayment(order);\n});

The orders module doesn't know that the payments module is listening. And later you extract payments into a separate service. Then you replace the in-process event bus with a message broker. The internal code of the module stays the same.

Owning data without separate databases

You don't need a separate database for each module. A separate schema, or even a simple table-ownership convention, is already enough:

// modules/catalog/catalog.repository.ts\n\nclass CatalogRepository {\n  // This module owns these tables. No other module touches them.\n  private readonly TABLES = {\n    products: 'catalog_products',\n    categories: 'catalog_categories',\n  } as const;\n\n  async getById(id: string): Promise<Product | null> {\n    const row = await db.query(\n      `SELECT * FROM ${this.TABLES.products} WHERE id = $1`,\n      [id]\n    );\n    return row ? this.toProduct(row) : null;\n  }\n}

Add to the tables the module name as a prefix: catalog owns the catalog_* tables, orders owns orders_*. When one module needs the data of another module, it goes through the public API, never through a cross-module SELECT.

The first time when someone joins directly into the tables of another module, you have already rebuilt the tangled monolith which you tried to avoid. So be strict with this rule.

And when you finally pull a module out

There are real reasons in order to extract a module into a separate service. Independent scaling, when one module needs much more compute than the others, and you don't want to scale the whole application only because of it. A different runtime, for example a module that needs a GPU, another programming language, or its own release schedule. On larger teams the coordination overhead itself becomes the bottleneck, and there a separate deployable for each team can be worth the cost. And fault isolation, when the failures of one module constantly takes down unrelated features.

If you have already done the modular-monolith work, the extraction is mostly mechanical. The module already has a defined interface. You put a network boundary where the function-call boundary was before. You replace the event bus with a message queue. And most of the work is done.

A few things to do before you start. From the very first commit already you must enforce the boundaries with the linting and the review, do not wait with this. And the event bus you should also build early, even in the moment when still nothing needs it. Because to add these two things into a big codebase later, this is exactly the slow and the painful part.

\n","headings",[47,54,57,60,63,66],{"_48":49,"_50":51,"_52":53},"id","what-it-actually-is","text","What it actually is","depth",2,{"_48":55,"_50":56,"_52":53},"the-cost-microservices-add","The cost microservices add",{"_48":58,"_50":59,"_52":53},"project-structure","Project structure",{"_48":61,"_50":62,"_52":53},"how-do-the-modules-talk-to-each-other","How do the modules talk to each other",{"_48":64,"_50":65,"_52":53},"owning-data-without-separate-databases","Owning data without separate databases",{"_48":67,"_50":68,"_52":53},"and-when-you-finally-pull-a-module-out","And when you finally pull a module out","page",1,"totalPages","tag","allTags",[38,75,76,77,78,79,80,39,81,82,40,83,84,85,86,87,88,89],"CSS","Database","Databases","Docker","Finance","Homelab","Linux","Networking","Performance","PostgreSQL","Project","Proxmox","React","TypeScript","Ubuntu","total","actionData","errors"]

Tech Notes

Tech tips and new discoveries

The Modular Monolith: A Practical Middle Ground