system-design · intermediate

Splitting a Monolith Safely (Strangler Fig)

Start here

Splitting a Monolith Safely (Strangler Fig) is a practical idea you will meet while building and operating real systems.

In plain English: it helps teams shape how internet-facing backend handles user requests and persistent records so the product stays correct, fast enough, and operable when something breaks.

Think of it like a growing shop that adds counters, storerooms, and delivery routes carefully. The analogy will guide intuition; later sections mark where software diverges.

You should care because skipping this topic usually means paying tuition during incidents—outages, silent data issues, or designs that cannot evolve. This lesson assumes you are capable but new to the details. Important terms are defined before they are reused as shorthand.

What you will learn

1. Explain Splitting a Monolith Safely (Strangler Fig) in plain English without unexplained jargon.
2. Describe the problem that appears when teams ignore it.
3. Walk through how it works step by step with a concrete system.
4. Apply a complete worked example using internet-facing backend.
5. Recognize common failure modes and how to detect them.
6. Weigh trade-offs so you can choose deliberately, not by fashion.
7. Practice with questions you can answer in writing or at a whiteboard.

What you should know first

You can continue even if some rows are fuzzy—the lesson re-explains what it needs in context.

Words you need before we begin

Simple story

Imagine a growing shop that adds counters, storerooms, and delivery routes carefully.

In that world, people invent informal rules so work keeps moving when someone is late, a tool breaks, or two people grab the same task. Splitting a Monolith Safely (Strangler Fig) is the engineered version of those rules for software: explicit, testable, and visible in metrics.

Where the analogy stops: software adds concurrency, multi-tenant blast radius, automated retries, partial network failure, and adversarial traffic. Always re-check the analogy against a real request or data path before copying it into production design.

The problem without this concept

Without a clear approach to Splitting a Monolith Safely (Strangler Fig), teams often:

1. Discover edge cases only in production under peak load.
2. Argue from anecdotes instead of shared definitions and metrics.
3. Patch symptoms (more retries, bigger machines) that increase hot keys, cascading timeouts, or unbounded queues.
4. Couple components so tightly that a single dependency outage becomes a user-facing outage.

Step-by-step explanation

Step 1 — Name the user-visible success

Write what “good” means for a journey that depends on Splitting a Monolith Safely (Strangler Fig). Example for internet-facing backend: the user receives a correct outcome for user requests and persistent records within an agreed latency budget, or a clear error they can act on—not a spinner forever.

Step 2 — Identify the moving parts

List the components that participate: clients, APIs, data stores, workers, caches, and third parties. Mark which are on the critical path versus optional enrichment.

Step 3 — Define invariants and failure language

State invariants involving Splitting a Monolith Safely (Strangler Fig). Example: “we never apply the same logical effect twice,” or “we never serve unauthorized data,” or “we degrade optional features before failing money paths.” Choose language your on-call can use in a war room.

Step 4 — Design the happy path

Walk one request or job from start to durable result. Name the storage writes, the network hops, and the acknowledgements. Keep the path short enough to explain on a whiteboard.

Step 5 — Design the unhappy path on purpose

For each dependency, pick timeout, retry policy (only if safe), fallback, and whether to fail open or fail closed. Unbounded retries without jitter are how retry storms start.

Step 6 — Make effects safe under at-least-once realities

Networks and workers duplicate messages. Prefer idempotency keys, unique constraints, and explicit state machines for user requests and persistent records. Assume redelivery.

Step 7 — Instrument before wide rollout

Add metrics and logs that show latency percentiles, error budgets, and capacity plans. If you cannot see hot keys, cascading timeouts, or unbounded queues, you cannot operate Splitting a Monolith Safely (Strangler Fig).

Step 8 — Roll out with limited blast radius

Feature flags, canaries, or shadow traffic. Document rollback. Prefer progressive exposure over big-bang cutovers for risky changes related to Splitting a Monolith Safely (Strangler Fig).

Visual mental model

flowchart TB
  U[User or upstream client] --> E[Edge / API]
  E --> C[Core logic for Splitting a Monolith Safely (Strangler Fig)]
  C --> S[(Durable state)]
  C --> X[Dependencies]
  C --> O[Observability signals]
  X -->|timeouts / retries / isolation| C
  O --> H[Humans on-call]

Learning question: Which box is most often missing from slideware about Splitting a Monolith Safely (Strangler Fig)—and what breaks when it is missing?

Caption: Benefits attract adoption; failure handling and observability keep systems honest.

Complete worked example: internet-facing backend

Starting situation

A team runs internet-facing backend. Peak traffic is rising. They need Splitting a Monolith Safely (Strangler Fig) to keep user requests and persistent records correct while staying within latency and error budgets.

Constraints

• Core paths must stay correct under retries and partial failure.
• On-call must diagnose issues using dashboards without SSH folklore.
• Changes should be reversible within a known window.
• Budget limits how many new moving parts they can operate well.

Decisions

1. Define user-visible success metrics tied to Splitting a Monolith Safely (Strangler Fig).
2. Keep critical-path dependencies bounded with timeouts and isolation.
3. Push non-critical work off the request path when possible.
4. Persist enough state to make retries idempotent for user requests and persistent records.
5. Add alerts on symptoms users feel—not only on CPU.
6. Ship behind a flag with a documented rollback.

Execution

1. Implement the happy path with clear module boundaries.
2. Add tests for unhappy paths: timeouts, duplicates, permission failures.
3. Load-test a realistic mix, including dependency slowdowns.
4. Enable for a small cohort; watch latency percentiles, error budgets, and capacity plans.
5. Expand gradually; freeze expansion if error budgets burn too fast.

Failure behavior samples

Outcome

The team can explain Splitting a Monolith Safely (Strangler Fig) with numbers: latency, error rate, and a specific health signal. Limitations remain—compliance, multi-region, or provider quirks may force adaptations—but the questions stay stable.

What we explicitly did not do

We did not pretend a single pattern removes all trade-offs. We also did not add unbounded queues or infinite retries as a substitute for capacity and good boundaries.

How it works in production

Ownership

Name a team for configuration, dashboards, and incidents touching Splitting a Monolith Safely (Strangler Fig). Unowned subsystems become unpageable mysteries.

Operational checklist

• Dashboards for latency, errors, and saturation on affected journeys
• Alerts on user-journey impact, not only instance CPU
• Runbooks for the top failure modes listed below
• Tests for unhappy paths in CI
• Capacity notes for peak events
• Change management: canaries and rollback

Signals that matter

• Latency percentiles (p50/p95/p99) on user-visible routes
• Error rate and saturation (pools, queues, connections)
• A specific health indicator for Splitting a Monolith Safely (Strangler Fig) (lag, hit rate, lock wait, auth failures—pick what fits)
• Deploy markers correlated with regressions

Deployment concerns

Prefer small releases. Configuration for timeouts and limits is as dangerous as code—review it like code. Keep feature flags for risky paths related to Splitting a Monolith Safely (Strangler Fig).

Failure modes

For each mode, practice saying: trigger → user experience → system view → detect → mitigate → prevent.

Trade-offs

There is no free lunch. Good engineering makes the trade-offs explicit and revisits them when load or product goals change.

Compare with related concepts

Related lessons to read next:

1. microservices-architecture
2. change-data-capture-vs-dual-writes
3. zero-downtime-schema-migration
4. distributed-transactions-saga

Common misunderstandings

1. “If it works on my laptop, production will be fine.”

1. “More retries fix reliability.”

1. “Async means we can ignore failures.”

1. “A cache removes the need for correct data modeling.”

1. “Exactly-once is a checkbox.”

1. “Microservices automatically isolate failure.”

1. “Observability is optional polish.”

Check your understanding

1. Define Splitting a Monolith Safely (Strangler Fig) in one or two sentences without jargon.
2. What problem appears when teams skip it?
3. Name two invariants you would protect in internet-facing backend.
4. Give one sync and one async choice that might appear near this topic.
5. What metric would tell you users are hurting?
6. Describe a failure mode and its first mitigation.
7. What trade-off would you explicitly tell a product manager about?

Practice

1. Draw the happy path for internet-facing backend involving Splitting a Monolith Safely (Strangler Fig). Mark the critical path in bold.
2. Write timeout and retry rules for one dependency that affects user requests and persistent records.
3. Design an idempotency approach for a duplicated request or message.
4. List three dashboard panels and one page-worthy alert.
5. Write a rollback plan for a bad config related to this topic.
6. Explain the simple story to a new hire, then state where it breaks.
7. Given a 10× traffic spike, which failure mode from the table hits first—and why?
8. Draft a short design-review checklist item that would have caught a past bug on your team.

Deeper production notes

Capacity napkin math

Estimate peak operations/second related to Splitting a Monolith Safely (Strangler Fig), multiply by cost per operation (CPU, IO, external API), and ask whether the design still works when a dependency runs at half capacity. If the answer depends on luck, add bounds, caching, shedding, or backlog limits before the marketing campaign.

Mixed-version deploys

During rollouts, old and new binaries coexist. Ensure protocols, message fields, and transaction assumptions tolerate one deploy window of mixed versions. Breaking changes need dual-write/dual-read plans or gated flags.

Ownership and support

If you cannot name who gets paged, who can change config, and who maintains dashboards, the mechanism is not production-ready—regardless of how elegant the code looks.

Security and privacy touchpoints

Wherever user requests and persistent records includes personal or financial data, apply least privilege, audit access, and careful logging (avoid secrets in plain logs). Security is not a separate optional chapter for real systems.

Testing strategy

Unit tests catch logic bugs; contract tests catch integration skew; load tests catch saturation; game days catch operational blind spots. Untested unhappy paths become production curricula.

Revision summary

• Splitting a Monolith Safely (Strangler Fig) is a concrete lever for correctness, performance, or operability—not a buzzword.
• Start from user-visible success, then design happy and unhappy paths.
• Bound timeouts, retries, and queues; prefer idempotent effects for user requests and persistent records.
• Instrument what users feel; assign owners; roll out with limited blast radius.
• Make trade-offs explicit and revisit them as load and product goals change.
• Related reading and practice above turn recognition into skill.

Glossary

Abbreviations and terminology

• API — Application Programming Interface
• SLO — Service Level Objective
• p95 / p99 — Latency percentiles
• TTL — Time To Live
• DLQ — Dead-Letter Queue
• MTTR — Mean Time To Recovery

What to learn next

1. microservices-architecture
2. change-data-capture-vs-dual-writes
3. zero-downtime-schema-migration
4. distributed-transactions-saga

FAQ from first-time learners

Q: Is Splitting a Monolith Safely (Strangler Fig) only for big companies?
A: No. Small systems still retry, fail, and grow. Lightweight versions of these ideas prevent painful rewrites.

Q: How do I know we are done designing?
A: You can explain happy path, top failures, metrics, owners, and trade-offs without hand-waving—and tests cover at least one unhappy path.

Q: What if our constraints differ from the worked example?
A: Keep the questions; change the mechanisms. The example is a template for judgment, not a mandatory architecture.

Q: Should we copy a famous company’s diagram?
A: Copy questions and principles, not cargo-cult boxes. Their scale, staffing, and history are not yours.

Q: How does this show up in interviews?
A: Interviewers listen for requirements, estimates, request paths, bottlenecks, and failure talk. Use the structure here as a spine.

Final field checklist

Before you claim Splitting a Monolith Safely (Strangler Fig) is production-ready for internet-facing backend:

1. User success is defined and measurable.
2. Critical vs non-critical dependencies are labeled.
3. Timeouts and retry policies are explicit and safe.
4. Duplicate application of effects is handled.
5. Dashboards and alerts exist and are owned.
6. Rollback / degrade paths are documented.
7. Load or failure testing touched the unhappy path.
8. Trade-offs are written where future readers will find them.

Track: Software Design and Architecture

Previous: Service Discovery — Finding Instances That Change

Next: Stateful vs. Stateless Architecture — Managing Session State

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab