Monolith vs. Microservices — Software Architecture Exercises

1 / 5

A CTO announces: "We're using the strangler fig pattern to migrate our five-year-old Rails monolith to services." A new engineer asks what this migration strategy involves in practice. Which description is correct?

Strangler fig pattern vocabulary:

The term comes from the strangler fig tree, which grows around an existing tree and eventually replaces it. The migration metaphor is precise: new services grow alongside the monolith, taking over functionality incrementally until the monolith is no longer needed.

Concept	Vocabulary
Strangler fig migration	Incremental extraction; route-level strangling; facade routing; coexistence period; gradual decommission
Big-bang rewrite	The anti-pattern — full parallel rewrite with hard cutover; high risk; rarely succeeds as planned
Strangler facade	A routing layer (often an API gateway or reverse proxy) that directs requests to either the monolith or the new service based on the migration state

Standard migration vocabulary sequence:

"Identify the seam" — find a cohesive capability with a clear external interface to extract first
"Build alongside" — develop the new service without touching the monolith
"Reroute traffic" — use the strangler facade to redirect the extracted capability to the new service
"Dark launch / shadow mode" — run both in parallel, compare outputs before committing
"Strangle" — remove the capability from the monolith once the new service is proven

2 / 5

A principal engineer says: "The User entity in our authentication service has a different bounded context from the User entity in the billing service — they should not share a model." What does bounded context mean in this microservices discussion?

Bounded context vocabulary — Domain-Driven Design in microservices:

Bounded context is one of the most important DDD concepts applied to microservices design. The key insight is that a single word (like "User" or "Order") does not have a universal meaning across an entire organisation — its meaning is valid within a specific context, and different contexts legitimately have different models.

Context	User entity contains	Domain language
Authentication service	email, passwordHash, mfaEnabled, lastLogin, sessionTokens	identity, credential, session, permission
Billing service	customerId, paymentMethods, billingAddress, invoiceHistory, taxId	customer, subscription, invoice, payment method
Notification service	userId, emailPreferences, pushTokens, notificationHistory	recipient, channel, preference, delivery

Key DDD vocabulary for microservices architecture discussions:

Ubiquitous language: the shared vocabulary used consistently within a bounded context — defined with domain experts, used in code, docs, and conversations
Context map: a diagram showing how bounded contexts relate and how they share or translate data across boundaries
Anti-corruption layer (ACL): a translation layer at the boundary between two contexts that prevents one context's model from "polluting" another's
Shared kernel: a small subset of the domain model intentionally shared between two contexts — used sparingly because it creates coupling

3 / 5

An engineering manager says: "We're reorganising our monolith into modules that match our new team structure — Conway's Law suggests the architecture will follow." What does Conway's Law state, and why is it directly relevant to this architectural decision?

Conway's Law vocabulary — organisation and architecture alignment:

Melvin Conway's 1967 observation is one of the most cited concepts in modern microservices discussions. The original formulation: "organisations which design systems are constrained to produce designs which are copies of the communication structures of those organisations."

Concept	Vocabulary	Practical implication
Conway's Law	"Systems mirror communication structures"	If your team has hard boundaries, your system will too — whether you intend it or not
Inverse Conway Maneuver	"Design your team structure to produce the architecture you want"	Deliberately reorganise teams around desired service boundaries before splitting the monolith
Team Topologies	stream-aligned team, enabling team, platform team, complicated subsystem team	A vocabulary for org design that deliberately applies Conway's Law to produce wanted architecture

Architecture discussion phrases:

"If we split the team before aligning the service boundaries, Conway's Law predicts we'll get accidental service cuts that don't match the domain."
"We're applying the Inverse Conway Maneuver — restructure the team first, then the architecture follows organisationally."

4 / 5

In an architecture review, an engineer argues against microservices: "You trade deployment independence for operational overhead." When an architect asks them to be specific, which set of operational concerns best captures what "operational overhead" means in this context?

Microservices operational overhead vocabulary — comprehensive list:

Option C is the correct and complete answer. Operational overhead in a microservices architecture spans multiple concerns that simply do not exist in a monolith where all code executes in the same process.

Operational concern	Monolith	Microservices
Service discovery	Not needed — function calls are in-process	Required — services must find each other dynamically; needs Consul, Kubernetes DNS, or a service mesh
Distributed tracing	Stack trace in one log	Requires trace context propagation (e.g., OpenTelemetry), centralised tracing (Jaeger, Zipkin)
Inter-service auth	Not needed in-process	Every service call must be authenticated (mTLS, JWT, service accounts)
Deployment pipelines	One pipeline	One pipeline per service — versioning, blue/green, canary, rollback for each
Distributed transactions	Local ACID transaction	Requires Saga pattern or 2PC — complex to implement and debug correctly

Architecture review phrasing: "Before splitting this service, we need to confirm the team has capacity for the operational overhead: distributed tracing, inter-service authorisation, a new deployment pipeline, and a strategy for the cross-service transaction on checkout. This is not free complexity."

5 / 5

A VP of Engineering asks a principal engineer: "We're a 12-person startup. Should we go with microservices from day one?" The engineer recommends a modular monolith instead. Which argument best justifies this recommendation?

Modular monolith vocabulary — the case against premature microservices:

The modular monolith recommendation is one of the most important architectural judgements a senior engineer can demonstrate, precisely because it resists the hype cycle and applies evidence-based reasoning about where complexity is justified.

Architecture	Internal structure	Deployment unit	When appropriate
Modular monolith	Well-defined modules with explicit interfaces; no cross-module direct data access	Single deployable artifact	Small teams; early stage; scale doesn't yet justify distributed complexity
Big ball of mud	No internal structure; everything calls everything	Single deployable artifact	Never — the anti-pattern of "monolith" people actually mean when criticising monoliths
Microservices	Independent services with network boundaries	Many independent deployable artifacts	Large teams; scale requires independent deployment; bounded contexts are stable

Key vocabulary phrases for this argument:

"A modular monolith gives us the architectural discipline of microservices without the operational overhead — we can extract a module into a service later when we have a team dedicated to it."
"Microservices are a solution to scale and team autonomy problems. We don't have those problems yet. Premature extraction would just add distributed systems complexity without the benefits."
"The migration path is clear: harden the module boundary first, then extract. Extracting a well-bounded module is straightforward. Extracting a tangled module is expensive regardless of the migration pattern."