Is it possible to split the database?

[prakhar-perennial]

I am trying to build a system that will connect to multiple other systems and occasionally, heavy bursts of traffic is expected. For the sake of stability and performance, I would like to go with a database per service model where every worker will serve just one domain. Is it possible to have that kind of deployment where I can have something like a "Product worker" with its own product database so I can scale only the workers that needs scaling?

[Vallabh-Mahanta]

Yes, it's possible to implement a database-per-service model in Medusa.

• Medusa already supports worker mode separation (server and worker instances) As it uses Redis for distributed transactions and event handling.
• Has a modular architecture with separate services ( Each module can operate independently in worker mode ).

Create separate Medusa instances for each domain (e.g., Products, Orders, Customers)
Each instance has its own database and worker
Use Medusa's plugin system to maintain service boundaries

Based on analysis of Medusa's worker mode and module architecture in
packages/core/types/src/common/config-module.ts
and
packages/core/modules-sdk/src/medusa-app.ts

I can say that the config-module.ts and medusa-app.ts show how services can be isolated.

Each service can have its own:

• Database connection
• Worker processes
• API endpoints
• Resource allocation

[Vallabh-Mahanta]

Hope this Helped.

[prakhar-perennial]

@Vallabh-Mahanta thanks for the response but I don't understand how these independent services will communicate with each other. Is there some built-in service discovery? if not then how do I tell a service how to communicate(IP/URL) with other? For example the Order service might need Products.

[Vallabh-Mahanta]

path : medusa/packages/modules/order/src/services/order-module-service.ts

@prakhar-perennial Medusa handles service communication through dependency injection rather than traditional service discovery. The Order service accesses Product functionality via direct module dependencies registered in MedusaModule . When needing cross-module access, services are injected like this:

import { ProductService } from "@medusajs/product"

export class OrderModuleService {
  constructor(
    // ...
    @Inject(MedusaServices.PRODUCT)
    protected readonly productService: ProductService
  ) {}

  async createOrder(data: CreateOrderDTO) {
    const product = await this.productService.retrieve(data.product_id)
    // ...
  }
}

This pattern avoids network calls while maintaining module isolation through TypeScript interfaces. For database-per-service scenarios, the Transaction Manager in TransactionBaseService coordinates distributed transactions across modules.

[prakhar-perennial]

Does that mean that I can break down the database but not the process itself? So, if I want to scale in a containerized environment, I will have to scale the entire monolith?

[Vallabh-Mahanta]

Create separate deployments for each service module. Set environment-specific DB configurations. Use Medusa's Redis-backed TransactionManager for cross-service transactions. This architecture allows scaling individual domain services without affecting others. The monolith only needs scaling if multiple domains are bundled in a single deployment.

You can scale individual services in a containerized environment by creating separate deployments for each module, but if the monolith includes multiple services, you may still need to scale the whole monolith if those services are tightly bundled together.