Published: September 7, 2026 · Last updated: September 7, 2026 · Author: Softix
The modular monolith vs microservices choice is rarely a purity contest. For US SMB founders and product/ops leaders, it is an operating decision: how many deployables can you honestly own, how fast can you ship a coherent product, and when does network isolation pay for itself?
Most early SaaS teams over-adopt microservices. Softix’s default is different: start with a modular monolith—one deployable application with clear domain modules—then extract services only when independent scale, deploy cadence, or team ownership is proven. Softix calls that path Bound–Enforce–Extract.
This brief sits beside Softix’s multi-tenant Postgres Pool–Policy–Escape guide, the REST vs GraphQL product-engineering scorecard, and feature-flag release discipline. Architecture style, tenancy, API contract, and release control are related—but they are not the same decision.
What Softix means by each shape
A monolith is one deployable that runs your product’s core request path. A modular monolith is still one deployable, but the codebase is partitioned into modules with explicit APIs, forbidden internals, and ownership. Microservices split those modules into separately deployed processes (often with separate data stores), communicating over the network.
Microservices can be right. They are also a force multiplier for complexity: distributed failures, partial deploys, cross-service authz bugs, and “who owns this incident?” meetings. Softix will not invent industry percentages to scare you. Softix will say this plainly: if your team cannot yet operate one modular codebase with CI architecture checks, multiplying processes will not create maturity—it will export chaos.
Industry practice at scale is more pragmatic than conference slides. In a June 2024 interview, Shopify principal engineer Oleksiy Kovyrin described Shopify Core as a large Rails “majestic monolith” split into domain components, with extraction reserved for clear cases such as storefront rendering—where a simpler, highly optimized path justified a separate application (Kovyrin interview). That is not a mandate to copy Shopify’s size. It is evidence that modularity inside one core can remain rational far longer than “microservices by default” marketing suggests.
Bound — Draw modules that match how the product runs
Bound means you name modules from real workflows—Billing, Catalog, Identity, Support Inbox—not from aspirational org charts. Each module gets:
- A public surface (types, services, or ports other modules may call).
- An internal package or folder other modules must not import.
- A data ownership story (which tables this module is allowed to write).
- An owner (person or small team) who can approve API changes.
Boundaries that only exist on a whiteboard fail the first sprint. Softix pairs Bound with tenancy and API choices: tenant isolation still belongs in the data layer (Pool–Policy–Escape), and module APIs should not become a second, ungoverned GraphQL surface by accident (REST vs GraphQL).
Prefer in-process events for module collaboration before you invent a message bus. Publish a domain event when an order is placed; let Inventory react in the same process (synchronously or asynchronously with a local outbox). You keep transactional clarity and avoid premature distributed choreography. Network events come later—when Extract proves you need them.
Shopify’s Packwerk retrospective is a useful caution for Bound: tools that enforce package graphs help only if the graph matches how code actually runs. Domain-named buckets that fight runtime dependencies create todo lists without isolation (Rails at Scale — Packwerk retrospective, 2024-01-26). Softix’s takeaway for SMBs: redraw the Bound when violations are structural, not only when developers are “naughty.”
Enforce — Make boundaries fail the build
Enforce turns architecture from hope into a fitness function. Softix expects at least one automated check in CI:
| Stack | What to use | What it proves |
|---|---|---|
| Java / Spring | Spring Modulith ApplicationModules.verify() |
No cycles; no access into module internals; optional allowed-dependency lists (verification docs) |
| Java (any) | ArchUnit package/slice rules | Layers and package dependencies checked as ordinary unit tests |
| Ruby / Rails | Packwerk-style constant boundary checks (used carefully) | Dependency edges held at the base layer; treat as a sharp knife per Shopify’s retrospective |
| Language modules | Java JPMS, ES modules with lint boundaries, Go internal packages | Compiler/tooling visibility limits where available |
Spring Modulith’s model is especially clear for Bound–Enforce: the application module’s top-level package is API; sub-packages are internal; verification rejects illegal references and module cycles (fundamentals). ArchUnit’s Library API can encode layered and slice rules the same way your team already runs tests (ArchUnit user guide).
Softix Enforce rules of thumb:
- Run architecture tests on every PR—not as a monthly “architecture review.”
- Freeze known debt if needed (ArchUnit freezing / todo lists), but stop new violations.
- Pair Enforce with feature flags so risky module rewrites can ship dark and retire cleanly.
- Measure what matters: build time, deploy frequency, incident ownership—not “number of services.”
Extract — Split only when independence is proven
Extract is optional. Softix extracts a module into a service when at least two of these are true and documented:
- Independent scale: One module’s CPU, memory, or queue depth forces expensive vertical scaling of the whole monolith, and horizontal scale of that slice alone is clearly cheaper.
- Independent deploy: The module needs a release cadence that constantly blocks or endangers the rest of the product.
- Independent team ownership: A durable team owns the module end-to-end (including on-call), with a stable API contract and versioning policy.
- Failure isolation that the network can buy: Blast radius must shrink in a way process isolation actually provides—after you already have module boundaries and good observability.
- Regulatory or tenancy Escape: A customer or region requires a silo that a module boundary cannot satisfy (align with Postgres Escape triggers).
Extract with a strangler pattern: keep the modular API, introduce a remote adapter behind the same port, dual-run, then cut over. Do not rewrite the product as twelve repos in one quarter.
Shopify’s storefront rendering split is the right mental model for Extract: a localized, high-traffic, relatively simple path justified a separate application; Kovyrin still expected most platform functionality to remain in Core for a long time (interview). Softix translates that for SMB SaaS: extract the outlier, not the org chart.
Bound–Enforce–Extract comparison
| Dimension | Modular monolith (Softix default) | Microservices (earned) |
|---|---|---|
| Deployables | One primary product deployable | Many independently deployed services |
| Boundaries | Packages/modules + CI fitness functions | Network APIs + contracts + more ops |
| Data | Shared DB with module write ownership (often) | Often separate stores; distributed consistency cost |
| Events | In-process / local outbox first | Brokers, schemas, consumer lag as day-two work |
| Team fit | Small product engineering team | Multiple owning teams with platform support |
| Failure mode | Large blast radius if modules are fake | Partial outages, cascading retries, unclear UX |
| When Softix chooses it | Default until Extract triggers fire | Proven scale/deploy/ownership independence |
A 30-day Bound–Enforce–Extract plan
Days 1–10 — Bound: List five workflows. Map modules and public APIs. Ban cross-module table writes. Introduce in-process events for two cross-module flows.
Days 11–20 — Enforce: Add ArchUnit or Spring Modulith (or equivalent) to CI. Baseline existing violations; block new ones. Document owners per module.
Days 21–30 — Extract readiness (not extraction): Write Extract triggers with product and ops. Pick one candidate module and design its port so a future remote adapter can replace the in-process implementation without rewriting callers. Ship any risky change behind a flag.
Risks and limits
- A “modular” folder tree without Enforce is a monolith with optimism.
- Microservices without product contracts become a distributed ball of mud.
- Shared-database microservices often keep the worst of both worlds.
- Softix does not cite unverified “X% of companies returned to monoliths” claims; if you see those numbers, demand the primary survey methodology.
- Custom product work still needs judgment—Softix’s custom software development practice is to choose the smallest architecture that protects delivery speed and tenant safety.
FAQ
Is a modular monolith “not real microservices prep”?
It is the best prep. Extract is cheaper when modules already have public APIs, ownership, and CI boundaries.
Should every SaaS start with Kubernetes and twenty services?
No. Start where your team can observe, deploy, and secure one system. Add process boundaries when Extract triggers are real.
Do we need Kafka on day one for modularity?
Usually no. Prefer in-process events and a local outbox. Introduce a broker when multiple deployables or external consumers need durable, independent consumption.
Softix CTA
If your roadmap is arguing microservices before Bound and Enforce exist, Softix can help you draw modules, wire CI fitness functions, and write Extract triggers that sales and engineering both respect. Explore custom software development or contact Softix for a scoped SaaS architecture review.
Share
