REPO LAYOUT VS. RUNTIME ARCHITECTURE

title: "Monorepo is not Monolith — and the difference decides your CVE response time"
published: false
description: "Repo layout and runtime topology are orthogonal axes. Here's what each one actually costs you in version control, updates, scaling, and scanning."
tags: architecture, devops, security, kubernetes
cover_image:

canonical_url:

Repo layout and deployment topology are orthogonal. Most orgs conflate them, split their runtime to solve a version-control problem, and end up with a distributed monolith that fails together, deploys together, and now also drops packets.

The decision that actually matters is where you enforce a boundary — compiler, or network — and you make that choice once per boundary, not once per company.

The two axes

What actually runs

A network call is a function call that acquired five new failure modes and lost its type checker. That's the entire trade:

The availability math nobody runs first

Services in a synchronous request path multiply, they don't average. For n services each at availability a :

At a respectable a=0.999 per service:

• Do two services have to be released in a fixed order? → not independent
• Do they share a database schema? → not independent
• Does one service's deploy require the other's integration suite? → not independent
• Does a single user story routinely touch 3+ repos? → boundaries follow the org chart, not the domain
• Is there a "shared-models" library every service pins? → you have a monolith with extra latency and a build step

Any of these = the costs of both architectures, the benefits of neither. Merge them back.

Version control and updates

An engineering drawing has one revision block. A drawing set has a rev per sheet plus an index saying which revs go together. That index is the whole problem with polyrepo microservices.

Scalability

The only scaling argument that survives contact is divergent resource profiles. If your resizer is CPU-bound and spiky while auth is memory-flat and steady, you're sizing every replica for the resizer and paying for idle auth 24/7. That's a real bill.

If every module has the same profile, splitting buys you a network hop and a Grafana dashboard.

Supply chain and scanning

This is where the two architectures invert, and where most security programs get it backwards.

The pattern that actually works, regardless of which side you land on:

golden base image (hardened UBI/distroless)
  └─> bump triggers rebuild of ALL dependents
        └─> SBOM + in-toto provenance attestation
              └─> cosign sign
                    └─> admission control verifies signature (Kyverno/Gatekeeper)
                          └─> Dependency-Track fleet inventory

The gate

Split a service out only if you can say yes to at least one trigger and yes to all the mitigations.

Triggers — at least one:

• Materially different resource profile (CPU vs memory, spiky vs flat)
• Materially different failure domain (this must survive when that dies)
• Materially different compliance boundary (this touches PII and that doesn't)
• A team that needs independent cadence and owns the whole domain
• Different scaling ceiling or language/runtime, with a real justification

Mitigations — all of them:

• Callers have timeouts, jittered retries, circuit breakers
• The service owns its data; no shared schema
• Contract tests in CI on both sides
• Distributed tracing before the first split, not after
• Golden base image with rebuild-on-bump
• Centralized admission policy and signed images

Not on the list, and never a valid trigger: "the codebase is big." Big is what modules are for.

Verdict

Start monorepo + modular monolith. Enforce module boundaries in CI (import linting, architecture tests) so the seams are real before they're physical. Split one service at a time, strangler-fig style, only against the gate above. Stay monorepo through the split — it's the cheapest insurance you'll ever buy against base-image drift.

Which axis does your org get wrong? I'd guess the one nobody wrote an ADR for.