Architecture scenarioHard~12 min

Interview question

A modular monolith is becoming tangled because modules call each other's services and tables directly. How would you restore enforceable boundaries without splitting into microservices?

Enforce boundaries inside a modular monolith

Turns a modular-monolith choice into enforceable code and data ownership rather than relying on folders and team discipline alone.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would define each module's public operations and owned data, then block direct references to its internals. Other modules call that public API or react to an internal event instead of querying its tables. Shared code stays small and foundational; business concepts should not move into a common project merely because two modules mention them. I would start with the highest-change or most tangled boundary rather than redesigning everything at once.

Full answer below

Practice focus

Module APIs, dependency rules, data ownership, internal events, transactions, architecture tests, and incremental untangling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A modular monolith needs explicit ownership even though it has one deployment. Folders alone do not prevent cross-module code and data access from creating one large dependency graph.
I would define each module's public operations and owned data, then block direct references to its internals. Other modules call that public API or react to an internal event instead of querying its tables. Shared code stays small and foundational; business concepts should not move into a common project merely because two modules mention them. I would start with the highest-change or most tangled boundary rather than redesigning everything at once.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Inside one process, module calls can remain ordinary method calls and can sometimes share a transaction deliberately. That is simpler than pretending every boundary is remote. Data ownership still matters: a reporting need can use a published read model or owned integration view instead of arbitrary joins across private tables. Architecture tests enforce project or namespace dependencies, while database permissions or schemas can strengthen high-value boundaries where practical.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I map the current dependency graph and choose a safe sequence. I add a facade around the target module, move consumers to it, then close direct code and table access. Cross-module events need clear delivery semantics; an in-process event before commit is different from an outbox event after durability. Telemetry includes module and operation names so coupling and latency stay visible. The result should preserve single-process simplicity while making extraction possible if a concrete ownership, scaling, or reliability need appears later.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Splitting into services before fixing ownership.
Using a shared project for all cross-module business models.
Calling private module handlers directly.
Publishing events without defining transaction timing.

Red flagsCandidateSigns the design is fragileSignals that an interviewer may treat as risky.Open details

Details

Every module can query every table.
Dependency cycles appear between modules.
A common project contains most business logic.
An internal call is designed as remote but still shares hidden state.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Can modules share one transaction?
How should one module read another's data?
What would make extraction worthwhile?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Prerequisite

Review this first if the current drill feels shaky.

Monolith vs Microservices

Opening drill

Architecture scenarioHard~12 min

Interview question

A modular monolith is becoming tangled because modules call each other's services and tables directly. How would you restore enforceable boundaries without splitting into microservices?

Enforce boundaries inside a modular monolith

Turns a modular-monolith choice into enforceable code and data ownership rather than relying on folders and team discipline alone.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Module APIs, dependency rules, data ownership, internal events, transactions, architecture tests, and incremental untangling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A modular monolith needs explicit ownership even though it has one deployment. Folders alone do not prevent cross-module code and data access from creating one large dependency graph.
I would define each module's public operations and owned data, then block direct references to its internals. Other modules call that public API or react to an internal event instead of querying its tables. Shared code stays small and foundational; business concepts should not move into a common project merely because two modules mention them. I would start with the highest-change or most tangled boundary rather than redesigning everything at once.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Inside one process, module calls can remain ordinary method calls and can sometimes share a transaction deliberately. That is simpler than pretending every boundary is remote. Data ownership still matters: a reporting need can use a published read model or owned integration view instead of arbitrary joins across private tables. Architecture tests enforce project or namespace dependencies, while database permissions or schemas can strengthen high-value boundaries where practical.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I map the current dependency graph and choose a safe sequence. I add a facade around the target module, move consumers to it, then close direct code and table access. Cross-module events need clear delivery semantics; an in-process event before commit is different from an outbox event after durability. Telemetry includes module and operation names so coupling and latency stay visible. The result should preserve single-process simplicity while making extraction possible if a concrete ownership, scaling, or reliability need appears later.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Splitting into services before fixing ownership.
Using a shared project for all cross-module business models.
Calling private module handlers directly.
Publishing events without defining transaction timing.

Red flagsCandidateSigns the design is fragileSignals that an interviewer may treat as risky.Open details

Details

Every module can query every table.
Dependency cycles appear between modules.
A common project contains most business logic.
An internal call is designed as remote but still shares hidden state.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Can modules share one transaction?
How should one module read another's data?
What would make extraction worthwhile?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Prerequisite

Review this first if the current drill feels shaky.

Monolith vs Microservices

A modular monolith is becoming tangled because modules call each other's services and tables directly. How would you restore enforceable boundaries without splitting into microservices?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Prerequisite

A modular monolith is becoming tangled because modules call each other's services and tables directly. How would you restore enforceable boundaries without splitting into microservices?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Prerequisite