5 exercises — practise the vocabulary of monolith-to-microservices discussions: the strangler fig migration pattern, bounded context from DDD, Conway's Law and the Inverse Conway Maneuver, operational overhead specifics, and the modular monolith recommendation.
0 / 10 completed
1 / 10
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.
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 / 10
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.
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 / 10
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 / 10
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?
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
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 / 10
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."
6 / 10
Code Review Comment: 'This service calls a database directly. Shouldn't we be using an API gateway for all external requests to decouple the services?' What architectural principle does this comment primarily highlight when discussing the shift from a monolith to microservices?
This comment focuses on reducing dependencies between services. Loose coupling is a core tenet of microservices architecture – minimizing direct interactions to promote independent development and deployment. Data duplication and the Single Responsibility Principle are related but don't directly address the issue raised in the comment. Eventual consistency, while relevant to distributed systems, isn't the immediate concern here.
7 / 10
Slack Message from @johndoe: 'Just noticed the billing service is generating a huge number of database queries. It's tightly coupled to the user profile data! We need to refactor.' What architectural issue is @johnDoe primarily raising when discussing the potential drawbacks of a monolithic approach compared to microservices?
The message highlights that the billing service is directly accessing user profile data. This indicates tight coupling—a major concern in microservices where services should ideally operate independently and not rely heavily on shared data. Increased latency and data redundancy are potential problems, but the core issue described is the lack of separation and isolation inherent in a monolithic structure. Scalability would be impacted by this tight coupling as well.
8 / 10
PR Description: 'Implemented new API endpoint for retrieving customer order history. This endpoint directly queries the Order database and returns all order details. This simplifies the integration with the reporting service.' Considering this PR within the context of moving to microservices, what potential architectural risk does it represent?
The description reveals a direct database query from the Order service. This creates a potential for data consistency conflicts if multiple services concurrently modify the same data. Microservices should ideally communicate through APIs and message queues to avoid this type of issue, promoting eventual consistency rather than immediate transactional guarantees. The other options aren't as directly relevant in this specific scenario.
9 / 10
Standup Update from @sarah: 'I've been working on improving the communication between our payment and inventory services. We're using a shared queue to handle order updates. It's complex to manage, though – we have multiple consumers and need to deal with potential message ordering issues.' What architectural concept is Sarah implicitly discussing when describing the use of a shared queue?
Sarah's description highlights using a shared queue for order updates. Eventual consistency is the principle where data inconsistencies are acceptable in a distributed system as long as the system eventually reaches a consistent state. The shared queue allows services to react asynchronously without requiring immediate synchronization – crucial for handling the complexities of microservices architectures. The other options relate to different patterns or techniques, but not the core challenge of managing consistency.
10 / 10
Architectural Discussion: 'We're considering breaking down our product catalog service into separate services for different product categories. Should we prioritize implementing this change based on the potential benefits of increased autonomy and independent scaling?
Domain-Driven Design (DDD) is a key approach to microservice architecture. Breaking down the product catalog based on distinct categories aligns with DDD's concept of bounded contexts – organizing services around specific business domains. This leads to more independent and scalable services, which are core benefits of adopting microservices. Performance optimization, fault tolerance, and the fundamental principles of microservices are important considerations but aren't the primary driver in this scenario.
What will I learn from the "Monolith vs. Microservices — Software Architecture Exercises" exercise?
Practice English for monolith vs. microservices architecture discussions: strangler fig migration, bounded context vocabulary, Conway's Law, operational overhead, and the modular monolith recommendation. 5 advanced exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Software Architecture exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss software architecture topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Software Architecture exercises?
See the full Software Architecture exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.