Start a SaaS Backend with Modules Before Adding Microservices

Define a booking module by the decisions it owns: whether a reservation can be created, changed, or canceled. Its callers should ask for those operations rather than update its tables directly. The boundary is visible in inputs, outcomes, and access rules, even when all modules run in the same application.

A notification module owns formatting and delivery attempts, but should not decide whether a booking exists. An availability module may supply schedule rules without independently committing reservations. Write down those responsibilities using a concrete request. A folder named bookings does little if every other module still edits its state through shared database helpers.

The package example exports one booking entry point. Node’s exports field can define supported package entry points and reject unlisted package subpaths. It helps communicate which code callers are intended to use. It is not a security sandbox and cannot replace repository import rules or review.

Keep the public operation close to the user action. A createBooking input should contain the validated intention and necessary actor context, not a raw HTTP request object or an arbitrary database transaction assembled by the caller. The operation can then be exercised from an API handler or worker without copying its rules.

If creating a reservation, acquiring occupancy, and saving its replay result belong to one PostgreSQL transaction, keeping them in one process can make that guarantee direct. A module boundary does not require a separate database or forbid a shared transaction coordinated by the owning operation.

Do not turn that convenience into permission for every module to write every table. Name the owner of each invariant and require callers to go through it. A transaction that spans unrelated responsibilities can become too broad, but a network split that removes atomicity has its own cost. Compare the actual recovery behaviour, not only the directory layout.

A remote operation can time out after its work succeeds. Deployments can expose incompatible versions, and events can arrive late or more than once. Microsoft’s architecture guidance treats these coordination and operational concerns as part of microservice design. They do not disappear because each individual codebase is smaller.

For the booking example, extracting notifications might create a useful failure boundary: slow delivery should not hold the reservation response open. Extracting occupancy prematurely could instead turn one local invariant into a distributed workflow. The answer depends on ownership, recovery needs, and deployment constraints rather than the number of folders.

Write a concrete reason to deploy a module separately: its resource usage interferes with another workload, its release cadence is independently constrained, or its isolation requirements cannot be satisfied within the current deployment. Measure the relevant behaviour before changing the topology. A hypothetical future traffic spike is not a complete extraction plan.

Also name the conditions under which the current arrangement remains appropriate. A small team with a coherent release process may gain little from operating additional services. Modules preserve an opportunity to separate later, but they should solve present ownership problems even if extraction never happens. Avoid adding remote-call abstractions solely to simulate a possible future.

Call the booking interface from a small test with an unavailable slot, a denied actor, and a successful reservation. Verify that unrelated modules cannot quietly bypass the intended write path. Review circular imports and direct table access as concrete boundary failures, not just stylistic preferences.

If extraction becomes justified, inventory the interface’s data, transactions, failure outcomes, and compatibility obligations. A boundary that was clear in one process still needs a network contract and durable recovery. Starting with modules earns a simpler initial system and better evidence for later decisions; it does not promise that splitting the system later will be automatic.