Module 01 · Lesson 11 of 14Free

Monoliths and microservices: choosing an architecture

Level

Intermediate

Topic

System design fundamentals

Reading time

18 min

Kartly handles about 50 requests a second on its single app server. A change to product suggestions is ready, but a checkout bug blocks the release.

“Should suggestions become a separate service?” asks the team. The question sounds like a code organization problem, but the answer changes how requests fail.

Which boundaries should stay inside Kartly, and which deserve their own deployment?

The traffic and server match Kartly’s current course stage. The blocked release and product-suggestion feature are this lesson’s illustrative scenario.

A release boundary is different

A monolith packages its application capabilities into one deployable unit. A modular monolith keeps that unit but gives its internal parts explicit interfaces and ownership. One deployment does not require tangled code. Shopify described choosing this approach in its 2019 engineering account.^{1Deconstructing the Monolith: Designing Software that Maximizes Developer ProductivityKirsten Westeinde, Shopify Engineering, 2019}

For this lesson, picture Kartly with catalog, checkout and suggestions modules:

A microservices architecture separates business capabilities into autonomous services. Each owns its data and exposes an interface. Independent deployment is a defining benefit; a small source file or a separate repository is not enough.^{3Microservices architecture styleMicrosoft, Azure Architecture Center, 2025}

Consider two proposed Kartly designs:

Neither row tells you how many machines exist. Use vertical and horizontal scaling to reason about replicas separately.

The opening release problem is real. But before moving code across a network, Kartly must ask whether its internal boundaries work at all.

Separate responsibilities before running services

In our initial implementation, the suggestions module reads catalog tables directly. Checkout also edits those tables to update stock. A catalog change can therefore break callers that its owner never intended to support.

That is coupling: one part depends on another part’s details. In this scenario, renaming a catalog column requires finding every caller.

Our proposed modular version changes those dependencies:

These are contracts, not necessarily HTTP endpoints. Initially, they are ordinary function interfaces inside Kartly.

Suppose checkout needs a product’s current title and price. Catalog returns a value containing those fields. Checkout does not receive a mutable catalog object or permission to edit catalog tables.

For this lesson’s design, checkout copies the agreed title and price into the order line. That snapshot belongs to the order. A later catalog rename must not rewrite a customer’s purchase history.

Make ownership enforceable

For our proposed Kartly implementation:

• Each module has a small public entry point.
• Callers import that entry point, not internal files.
• Automated import checks reject forbidden dependencies.
• Module owners review changes to public contracts.
• Queries that access another module’s tables move behind its interface.

These rules make the boundary more than a folder name. Without enforcement, the next urgent feature can restore the old shortcuts.

Shopify’s account describes defining and respecting component boundaries without splitting the application into services. That is evidence for the approach, not a claim that every monolith will remain manageable indefinitely.^{1Deconstructing the Monolith: Designing Software that Maximizes Developer ProductivityKirsten Westeinde, Shopify Engineering, 2019}

Kartly now has a concrete alternative to extraction. It can improve ownership without adding another runtime dependency.

Choose the cheapest useful boundary

This reasoning follows Fowler’s warning that services add their own development and operating costs. His recommendation is to preserve modularity without distributing a system before its complexity justifies that cost.^{2Microservice PremiumMartin Fowler, martinfowler.com, 2015}

Keep the decision testable. In our scenario, record blocked-release time, the reason for each block and the modules changed together.

If most “suggestions changes” also modify checkout, the boundary is not ready for independent deployment. If they rarely overlap, extraction becomes more plausible.

A better code boundary gives Kartly options. It does not yet reveal the most important cost of using those options.

A remote call has uncertainty

Imagine a later experiment: Kartly moves suggestions into a separately deployed service. This is a hypothetical extension, not a change to Kartly’s current course stage.

Inside the application, the caller receives a return value or a local error. Across a network, a timeout adds another possibility: the caller does not know whether the remote work completed.

Distributed services introduce communication, consistency and failure-handling costs. Long chains of calls can also add latency.^{3Microservices architecture styleMicrosoft, Azure Architecture Center, 2025}

For our extraction experiment, set a 100 ms deadline for suggestions. The page’s core product information must not wait longer for this optional feature.

Trace one request:

1. Kartly receives a product-page request.
2. It requests suggestions with a product ID.
3. The service computes a list of suggested IDs.
4. The reply does not reach Kartly before its deadline.
5. Kartly returns the product page without the suggestions section.

The user can still inspect the product. The missing section is preferable to a frozen page.

That behavior is a design choice, not an automatic property of services. If Kartly waits indefinitely, the separate service still blocks the page.

A partial failure means one part fails while another remains operational. In this experiment, the suggestions service might be healthy even though communication with Kartly fails.

Retries depend on the operation

Our suggestion lookup has no write effect, so repeating it cannot create another order. Still, we choose no immediate retry on the page path: another attempt would spend the remaining deadline and add work during trouble.

Now imagine moving order creation across the same boundary. Repeating an uncertain request could create another order. That operation needs idempotency, not a general “retry every timeout” rule.

The network boundary therefore changes the contract. Kartly must define deadlines, fallback behavior and retry rules alongside request and response fields.

Data ownership determines real independence

A separate suggestions process is not independent if it reaches into catalog’s tables. Catalog cannot safely rename a column until every deployed reader changes.

Microsoft’s guidance connects service autonomy with private data ownership and stable interfaces. Shared schemas and rigid protocols create dependencies across service boundaries.^{3Microservices architecture styleMicrosoft, Azure Architecture Center, 2025}

Apply that principle to our experiment:

Suppose suggestions returns IDs for products that were removed moments earlier. Kartly’s page assembly checks those IDs through catalog and omits missing products. Our scenario tolerates fewer suggestions; it does not tolerate inventing product details.

This keeps the service contract narrow. Suggestions selects IDs. Catalog decides whether those products currently exist.

Keep one atomic change together

Stock reservation creates a harder boundary.

For our initial design, catalog and checkout can participate in one PostgreSQL transaction. Either stock reservation and order creation commit together, or neither does. Module ownership does not require separate databases.

If those writes move into separately owned databases, an ordinary transaction on either database cannot cover both. Distributed coordination would need an additional protocol.

Imagine inventory reserves the last unit, then order creation fails. Someone must release that reservation or finish the order later. The customer must also see an honest intermediate result.

For Kartly, that recovery work is a reason to keep these tightly related writes together initially. Later, sagas examine workflows with explicit recovery across services.

A promising extraction boundary minimizes both shared releases and shared atomic changes.

Independence must repay operating costs

Return to the hypothetical suggestions service. Assume the team now has repeated evidence that its releases are blocked.

Independent deployment and scaling are potential service benefits. Fault isolation depends on callers handling failures correctly; process separation alone does not provide it.^{3Microservices architecture styleMicrosoft, Azure Architecture Center, 2025}

Before extraction, the team writes down this operating contract:

This table exposes an important limit: extracting suggestions does not remove Kartly’s database or pricing dependencies.

For the service itself, we require a health check, an owner, a compatible rollback and measurements of errors and timeouts. Recovery means replacing a failed instance or reverting a bad release, then checking that callers receive valid results again.

Use numbers without inventing savings

The following is an illustrative capacity calculation. Assume suggestions consumes 1 ms of CPU time per product-page request. Assume every request in the festival peak is such a page.

We have no measured service capacity or hosting price here. Therefore, this estimate supports investigation, not a machine count or a savings claim.

Release freedom needs compatible contracts

In our experiment, the service first returns a list of product IDs. Later, its team wants to return scores too.

They can preserve the existing ID field and add optional scores. Old callers continue using IDs. Removing IDs immediately would force Kartly and the service to deploy together.

A service boundary has failed its purpose if every change requires a synchronized release. Independent deployment requires compatible contracts, not just separate build jobs.^{3Microservices architecture styleMicrosoft, Azure Architecture Center, 2025}

For Kartly, make the extraction decision from evidence:

• How much blocked-release time disappeared?
• Did page latency or timeout frequency increase?
• How often did a service change still require a caller change?
• How much operating work did the new service introduce?

If release coordination remains unchanged, another service has not solved the original problem.

The earlier stateless and stateful services lesson explains what must survive instance replacement. Here, the additional question is who can change that state and its contract.

Where this shows up

• Design: a notification service: delivery is a distinct capability with its own failure and recovery behavior.
• Design: an e-commerce checkout: order, inventory and payment boundaries determine coordination work.

Kartly’s next question is whether the independence gained is worth the infrastructure and operating cost.

Common mistakes

Equating a monolith with one machine. A monolith describes a deployment boundary. Replicating it changes capacity, not its division into capabilities.

Calling folders independent services. In our design, a module becomes a service only when its runtime and deployment boundary move. A folder rename does neither.

Sharing tables after claiming independence. Kartly’s proposed service contract hides catalog’s schema. Direct table access would undo that separation.

Assuming a separate process protects users. In our timeout scenario, protection comes from the deadline and fallback. Without them, the page still waits.

These mistakes all confuse a visible boundary with the behavior that boundary must support.

Check your understanding

Summary