Comparison questionMedium~7 minSystem Design Foundations Essentials / 2 of 15

Interview question

A growing product is still one deployable application. When would you keep a modular monolith, and when would you split it into microservices?

Modular monolith vs microservices

Chooses between a modular monolith and microservices using domain boundaries, team ownership, scaling, deployment, data consistency, and operational cost.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would usually keep a modular monolith while the product can be owned, deployed, and scaled as one unit without blocking delivery. The code would still have explicit domain modules, controlled dependencies, and owned data so the architecture is not one undivided codebase. I would consider extracting a service when a boundary has a clear business purpose and needs independent ownership, deployment, scaling, technology, or fault isolation. Microservices add network failures, distributed data, versioned contracts, deployment coordination, and more operations, so those costs need a concrete payoff.

Full answer below

Practice focus

Service boundaries, ownership, independent deployment and scaling, transaction cost, failure isolation, observability, and evolutionary architecture.

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
The decision is not a maturity ladder where more services automatically mean a better system. It is a trade between local simplicity and the independence gained by crossing process and data boundaries.
I would usually keep a modular monolith while the product can be owned, deployed, and scaled as one unit without blocking delivery. The code would still have explicit domain modules, controlled dependencies, and owned data so the architecture is not one undivided codebase. I would consider extracting a service when a boundary has a clear business purpose and needs independent ownership, deployment, scaling, technology, or fault isolation. Microservices add network failures, distributed data, versioned contracts, deployment coordination, and more operations, so those costs need a concrete payoff.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would compare a proposed boundary across change cadence, load shape, transaction scope, reliability, and team ownership. If two modules change together and require one transaction, separating them often creates chatty calls and consistency problems. If one capability has distinct load, a stable contract, and a team that can own it end to end, separation may reduce coupling. Team count alone does not require process boundaries; multiple teams can own well-enforced modules in one deployment. Inside a modular monolith I would avoid arbitrary cross-module table access and expose module operations instead, which keeps later extraction possible without paying the distributed-systems tax early.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would treat decomposition as an incremental migration rather than a rewrite. First I would measure the coupling, establish a contract, and move data ownership to the intended boundary. An outbox or event bridge can support a gradual cutover while contract tests protect consumers. After extraction, the service must own its schema, deployment, telemetry, on-call behavior, and failure policy; a separately deployed controller over a shared database is not meaningful autonomy. I would also keep services coarse enough to preserve useful transactions and revisit a split if operational cost exceeds the independence it provides.

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 by technical layer instead of a business capability.
Creating services that still share tables and release together.
Assuming network calls behave like in-process method calls.
Choosing microservices because the product might grow someday.

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

Details

No specific independence benefit justifies a service boundary.
A single request requires long chains of synchronous service calls.
Data ownership and cross-service consistency are left unresolved.
The team lacks deployment, telemetry, and incident ownership for each service.

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.

What signals tell you a module is ready to extract?
How would you move a shared table behind one service boundary?
When is a distributed monolith worse than a modular monolith?

Continue the section

Next in System Design Foundations Essentials: Read Replicas & Lag

Step 3 of 15

Design read scaling with replicas and replication lag

Opening drill

Comparison questionMedium~7 minSystem Design Foundations Essentials / 2 of 15

Interview question

A growing product is still one deployable application. When would you keep a modular monolith, and when would you split it into microservices?

Modular monolith vs microservices

Chooses between a modular monolith and microservices using domain boundaries, team ownership, scaling, deployment, data consistency, and operational cost.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Service boundaries, ownership, independent deployment and scaling, transaction cost, failure isolation, observability, and evolutionary architecture.

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
The decision is not a maturity ladder where more services automatically mean a better system. It is a trade between local simplicity and the independence gained by crossing process and data boundaries.
I would usually keep a modular monolith while the product can be owned, deployed, and scaled as one unit without blocking delivery. The code would still have explicit domain modules, controlled dependencies, and owned data so the architecture is not one undivided codebase. I would consider extracting a service when a boundary has a clear business purpose and needs independent ownership, deployment, scaling, technology, or fault isolation. Microservices add network failures, distributed data, versioned contracts, deployment coordination, and more operations, so those costs need a concrete payoff.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would compare a proposed boundary across change cadence, load shape, transaction scope, reliability, and team ownership. If two modules change together and require one transaction, separating them often creates chatty calls and consistency problems. If one capability has distinct load, a stable contract, and a team that can own it end to end, separation may reduce coupling. Team count alone does not require process boundaries; multiple teams can own well-enforced modules in one deployment. Inside a modular monolith I would avoid arbitrary cross-module table access and expose module operations instead, which keeps later extraction possible without paying the distributed-systems tax early.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would treat decomposition as an incremental migration rather than a rewrite. First I would measure the coupling, establish a contract, and move data ownership to the intended boundary. An outbox or event bridge can support a gradual cutover while contract tests protect consumers. After extraction, the service must own its schema, deployment, telemetry, on-call behavior, and failure policy; a separately deployed controller over a shared database is not meaningful autonomy. I would also keep services coarse enough to preserve useful transactions and revisit a split if operational cost exceeds the independence it provides.

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 by technical layer instead of a business capability.
Creating services that still share tables and release together.
Assuming network calls behave like in-process method calls.
Choosing microservices because the product might grow someday.

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

Details

No specific independence benefit justifies a service boundary.
A single request requires long chains of synchronous service calls.
Data ownership and cross-service consistency are left unresolved.
The team lacks deployment, telemetry, and incident ownership for each service.

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.

What signals tell you a module is ready to extract?
How would you move a shared table behind one service boundary?
When is a distributed monolith worse than a modular monolith?

Continue the section

Next in System Design Foundations Essentials: Read Replicas & Lag

Step 3 of 15

Design read scaling with replicas and replication lag

A growing product is still one deployable application. When would you keep a modular monolith, and when would you split it into microservices?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A growing product is still one deployable application. When would you keep a modular monolith, and when would you split it into microservices?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section