5 exercises on opinion articles arguing for and against microservices and monoliths. Identify the author’s actual stance, distinguish claims from evidence, and recognise hedging language.
Reading technical opinion pieces effectively
Find the thesis — look for “My position is this”, “I am arguing that” — these signal the real claim
Hedging language — “almost always”, “in some cases”, “that said” qualify absolute-sounding claims
Claim vs. evidence — identify what the author asserts vs. what they offer to support it
Existence proofs — real-world examples that prove something is possible, countering hypothetical objections
Reframing — authors attack the cause attributed to a problem, not just the problem itself
0 / 5 completed
1 / 5
Passage: The Microservices Trap — Opinion Piece
Title: The Microservices Trap: Why Distributed Systems Are Not a Default
There is a quiet consensus forming in the industry that microservices — the architectural
pattern that dominated the 2010s — are frequently chosen for the wrong reasons. I want
to be careful here: I am not arguing that microservices are bad. I am arguing that they
are expensive, and that the bill comes due in ways most teams do not anticipate.
The case for microservices is legitimate. Independent deployability genuinely removes
coordination overhead when you have large teams working on well-separated domains.
Fault isolation means a memory leak in the recommendation engine does not take down
the checkout flow. These are real advantages.
But the case against default microservices is equally compelling. Every inter-service
boundary you draw is a distributed systems problem. You now need to reason about
network partitions, eventual consistency, and retry logic that simply does not exist
in a monolith. "Simple" CRUD operations that touch multiple services require distributed
transactions or sagas — both of which are significantly more complex than a database
transaction.
My position is this: the right answer depends almost entirely on team size and domain
clarity. Below roughly 20 engineers, a well-factored monolith is almost always the
correct choice. The overhead of microservices — service discovery, inter-service
authentication, distributed tracing, independent deployment pipelines — consumes
engineering capacity that a small team cannot afford to spare. You pay the microservices
tax before you receive the microservices dividend.
If you are reaching for microservices because they feel "more professional" or because
a large tech company uses them, reconsider. Netflix runs microservices with thousands
of engineers supporting the infrastructure. You do not.
Which sentence best describes the author's actual position on microservices?
Expensive and often unjustified, but legitimate in the right context.
The author flags the nuance immediately: "I am not arguing that microservices are bad. I am arguing that they are expensive." They then give conditions under which microservices are appropriate: large teams, well-separated domains, independent deployability. Their thesis is conditional, not absolute.
Identifying hedged opinion in tech writing:
"I want to be careful here" — signals a nuanced position, not a blanket condemnation.
"My position is this" — the thesis statement; read this sentence and the one after very closely.
"Below roughly 20 engineers... almost always" — a qualified claim, not a universal rule.
Why option A is wrong: Option A describes a stronger claim than the author makes. The author explicitly says the case for microservices is "legitimate" and that the advantages are "real." Reading opinion pieces requires distinguishing the author's actual claim from the strongest possible version of it.
2 / 5
Passage: The Microservices Trap — Opinion Piece
Title: The Microservices Trap: Why Distributed Systems Are Not a Default
There is a quiet consensus forming in the industry that microservices — the architectural
pattern that dominated the 2010s — are frequently chosen for the wrong reasons. I want
to be careful here: I am not arguing that microservices are bad. I am arguing that they
are expensive, and that the bill comes due in ways most teams do not anticipate.
The case for microservices is legitimate. Independent deployability genuinely removes
coordination overhead when you have large teams working on well-separated domains.
Fault isolation means a memory leak in the recommendation engine does not take down
the checkout flow. These are real advantages.
But the case against default microservices is equally compelling. Every inter-service
boundary you draw is a distributed systems problem. You now need to reason about
network partitions, eventual consistency, and retry logic that simply does not exist
in a monolith. "Simple" CRUD operations that touch multiple services require distributed
transactions or sagas — both of which are significantly more complex than a database
transaction.
My position is this: the right answer depends almost entirely on team size and domain
clarity. Below roughly 20 engineers, a well-factored monolith is almost always the
correct choice. The overhead of microservices — service discovery, inter-service
authentication, distributed tracing, independent deployment pipelines — consumes
engineering capacity that a small team cannot afford to spare. You pay the microservices
tax before you receive the microservices dividend.
If you are reaching for microservices because they feel "more professional" or because
a large tech company uses them, reconsider. Netflix runs microservices with thousands
of engineers supporting the infrastructure. You do not.
The author writes: "You pay the microservices tax before you receive the microservices dividend." What does this mean in context?
Upfront operational cost before delayed benefits.
This is a financial metaphor used to describe technical economics. The "tax" refers to the immediate costs listed in the preceding sentence: "service discovery, inter-service authentication, distributed tracing, independent deployment pipelines." These costs are paid from day one. The "dividend" refers to the benefits: independent deployability, fault isolation. But those benefits only pay off once your team and codebase are large enough to have coordination problems worth solving.
Identifying metaphors in opinion writing: Technical opinion pieces frequently use financial or physical metaphors to frame trade-offs. When you see tax, dividend, debt, investment, cost used in a non-financial context, map each term to its technical equivalent:
Tax → unavoidable overhead.
Dividend → delayed benefit.
Debt → accumulated technical shortcuts.
Option A takes the metaphor literally — a very common trap in technical reading comprehension.
3 / 5
Passage: The Microservices Trap — Opinion Piece
Title: The Microservices Trap: Why Distributed Systems Are Not a Default
There is a quiet consensus forming in the industry that microservices — the architectural
pattern that dominated the 2010s — are frequently chosen for the wrong reasons. I want
to be careful here: I am not arguing that microservices are bad. I am arguing that they
are expensive, and that the bill comes due in ways most teams do not anticipate.
The case for microservices is legitimate. Independent deployability genuinely removes
coordination overhead when you have large teams working on well-separated domains.
Fault isolation means a memory leak in the recommendation engine does not take down
the checkout flow. These are real advantages.
But the case against default microservices is equally compelling. Every inter-service
boundary you draw is a distributed systems problem. You now need to reason about
network partitions, eventual consistency, and retry logic that simply does not exist
in a monolith. "Simple" CRUD operations that touch multiple services require distributed
transactions or sagas — both of which are significantly more complex than a database
transaction.
My position is this: the right answer depends almost entirely on team size and domain
clarity. Below roughly 20 engineers, a well-factored monolith is almost always the
correct choice. The overhead of microservices — service discovery, inter-service
authentication, distributed tracing, independent deployment pipelines — consumes
engineering capacity that a small team cannot afford to spare. You pay the microservices
tax before you receive the microservices dividend.
If you are reaching for microservices because they feel "more professional" or because
a large tech company uses them, reconsider. Netflix runs microservices with thousands
of engineers supporting the infrastructure. You do not.
The author acknowledges that "the case for microservices is legitimate." What evidence do they give for this?
Independent deployability and fault isolation — stated as real advantages.
The passage says: "Independent deployability genuinely removes coordination overhead when you have large teams... Fault isolation means a memory leak in the recommendation engine does not take down the checkout flow. These are real advantages."
Distinguishing claim from evidence in opinion pieces:
A claim is an assertion: "microservices have real advantages."
Evidence is what the author gives to support it: specific named advantages with explanations of how they work.
Why the other options are wrong:
Option A — Netflix is mentioned, but in the last paragraph as a counterpoint to small teams, not as evidence for microservices' case.
Option C — no research is cited; the author relies on reasoning, not external data.
Option D paraphrases the "feeling more professional" warning, which the author explicitly argues against.
4 / 5
Passage: In Defence of the Boring Monolith — Opinion Piece
Title: In Defence of the Boring Monolith
Before you reach for Kubernetes, ask yourself: do I actually need this?
The monolith has become a term of mild embarrassment in some engineering circles, as
if "we run a monolith" is a confession of technical debt. I think this framing is wrong,
and in some cases actively harmful.
Shopify ran a Ruby on Rails monolith handling billions of dollars of commerce for over
a decade. Stack Overflow serves millions of developers with a handful of servers and
a straightforward .NET application. These are not cautionary tales — they are existence
proofs that a well-maintained monolith can scale remarkably far.
The argument against monoliths — that they become unmaintainable — is really an argument
against poorly-structured code, not against the deployment model. A monolith with
clear module boundaries, enforced by linting rules or package-private visibility, is
easier to reason about than a distributed system with unclear ownership.
That said, I am not arguing for the monolith in all circumstances. When your organisation
genuinely has independent teams that need to deploy on different cadences, or when a
specific component has dramatically different scaling requirements, microservices earn
their complexity cost. The key word is "earn."
The default should be the simplest system that meets your actual requirements — not
the most sophisticated system you can justify. Complexity is a liability, not an asset.
The author mentions Shopify and Stack Overflow. What rhetorical purpose do these examples serve?
Existence proofs — they prove it is possible by showing it has been done.
The author says this explicitly: "These are not cautionary tales — they are existence proofs that a well-maintained monolith can scale remarkably far."
Why "existence proof" is a powerful rhetorical move: In logic, an existence proof demonstrates that something is possible by producing at least one example. In tech writing, citing a successful real-world case short-circuits hypothetical objections. It is harder to argue "monoliths can't scale" when you can point to Shopify handling billions of dollars on one.
Reading the author's framing: The author explicitly tells you how to interpret the examples: "not cautionary tales" dismisses the alternative interpretation before you can form it. This pre-emptive framing is a common rhetorical technique — identify it and notice what interpretation the author is ruling out.
5 / 5
Passage: In Defence of the Boring Monolith — Opinion Piece
Title: In Defence of the Boring Monolith
Before you reach for Kubernetes, ask yourself: do I actually need this?
The monolith has become a term of mild embarrassment in some engineering circles, as
if "we run a monolith" is a confession of technical debt. I think this framing is wrong,
and in some cases actively harmful.
Shopify ran a Ruby on Rails monolith handling billions of dollars of commerce for over
a decade. Stack Overflow serves millions of developers with a handful of servers and
a straightforward .NET application. These are not cautionary tales — they are existence
proofs that a well-maintained monolith can scale remarkably far.
The argument against monoliths — that they become unmaintainable — is really an argument
against poorly-structured code, not against the deployment model. A monolith with
clear module boundaries, enforced by linting rules or package-private visibility, is
easier to reason about than a distributed system with unclear ownership.
That said, I am not arguing for the monolith in all circumstances. When your organisation
genuinely has independent teams that need to deploy on different cadences, or when a
specific component has dramatically different scaling requirements, microservices earn
their complexity cost. The key word is "earn."
The default should be the simplest system that meets your actual requirements — not
the most sophisticated system you can justify. Complexity is a liability, not an asset.
The author says: "The argument against monoliths... is really an argument against poorly-structured code, not against the deployment model." What is the author doing here?
Reframing the opposition's argument by attacking its root cause attribution.
This is a classic rhetorical move: the author accepts the observation (monoliths can become unmaintainable) but disputes the cause attributed to it. The standard argument blames the deployment model (monolith); the author says the real culprit is code structure. This is called redirecting causation.
Distinguishing claims from evidence in opinion writing:
The opposition's claim: monoliths become unmaintainable (inherent to the model).
The author's reframe: the actual cause is poor structure, which is separable from deployment model.
The author's supporting claim: a monolith with "clear module boundaries... is easier to reason about than a distributed system with unclear ownership."
Hedging language to notice: The author ends by qualifying their position: "That said, I am not arguing for the monolith in all circumstances." The phrase "that said" signals a concession or qualification — it softens the preceding absolute-sounding claim.