5 exercises — practise the vocabulary architects use to frame trade-offs precisely: "we optimise for X at the cost of Y", CQRS framing, explaining eventual consistency across audience levels, caching trade-off statements, and horizontal vs. vertical scaling.
0 / 10 completed
1 / 10
In a design review an architect says: "We optimise for read latency at the cost of write complexity." The system maintains a separate, denormalised read model that is updated asynchronously whenever a write command is executed. Which architectural pattern or approach does this describe?
Trade-off framing vocabulary — CQRS:
The phrase "we optimise for X at the cost of Y" is the standard architecture review framing for CQRS. The pattern explicitly accepts write-side complexity (maintaining projection logic, eventual consistency between models) in exchange for a queryable model tailored to the read access patterns.
Pattern
Trade-off phrasing
What is gained
What is accepted
CQRS
"we optimise for read latency at the cost of write complexity"
Denormalised, queryable read model; fast reads
Projection maintenance; eventual consistency between read and write models
Event Sourcing
"we gain a full audit log at the cost of read performance without projections"
Complete history, time-travel queries
Event replay overhead; projection rebuild cost
Sharding
"we gain write throughput at the cost of cross-shard query complexity"
Horizontal write scalability
Cross-shard joins, distributed aggregations
Key vocabulary:optimise for, at the cost of, we're trading X for Y, the accepted trade-off is. These phrases signal that the decision was deliberate, not accidental — which is exactly what architecture reviewers want to hear.
2 / 10
In a system design review, four different engineers describe the same architectural decision: adding read replicas to a PostgreSQL primary. Which statement communicates the trade-off with the most appropriate precision for an architecture review audience?
Trade-off communication vocabulary — precision and structure:
Option B is the only response that satisfies the criteria for a well-formed trade-off statement in an architecture review.
Option
What it says
Problem
A
"more scalable", "minimal risk"
Vague — no specific system attribute named; "minimal risk" is unqualified
Correct — names the gained property, the cost, and the constraint on consumers
C
"cleaner", "easier to reason about"
Subjective; zero technical content; states no trade-off at all
D
"industry best practice", "large companies use it"
Appeal to authority — not a trade-off argument; context-free
Trade-off statement structure:
Gain: name the specific system attribute you improve (latency, throughput, availability, scalability dimension)
Cost: name the specific attribute you sacrifice or complexity you introduce
Constraint: state what consumers of the system must now tolerate or handle
Template phrase:"By doing X, we gain [specific attribute] at the cost of [specific cost] — [consumers/callers/operators] must [handle constraint]."
3 / 10
A user reports: "I updated my profile photo but my colleague can still see the old one." A developer investigates and confirms the update was written successfully. Which explanation correctly communicates eventual consistency to a non-technical stakeholder?
Option D is the only response that explains the behaviour in non-technical language, confirms the write succeeded, sets correct expectations, and does not alarm the user with incorrect failure framing.
Option
Problem
A
Incorrect and alarming — implies data loss risk; conflates NoSQL with unreliability
B
Technically accurate but inaccessible — CAP theorem jargon is meaningless to a non-technical stakeholder
C
Incorrectly frames expected behaviour as a bug — will create unnecessary escalation
D
Correct — confirms success, explains the delay in plain language, sets expectation, offers action
Eventual consistency vocabulary by audience:
Audience
How to frame it
Non-technical stakeholder
"Changes propagate across the system within a few seconds — you always get a response, and the data catches up quickly"
Developer
"The system is AP — reads may return stale data for up to [N]ms after a write; callers must not assume read-your-writes consistency across regions"
Architecture review
"We accept eventual consistency on read replicas — the accepted staleness window is [N]ms; features requiring read-your-writes must write and read from the primary"
4 / 10
Your team is considering adding a Redis cache in front of the user profile service. In an architecture review, which statement correctly communicates this trade-off with appropriate specificity?
Option C demonstrates the correct vocabulary pattern: quantified gain, named cost, specified staleness window, and explicit constraint on consumers.
Element
Option C example
Why it matters
Quantified gain
"40ms → ~2ms read latency"
Reviewers can evaluate whether the gain justifies the cost
Named cost
"cache invalidation problem"
Names the specific problem, not "some consistency issues"
Staleness window
"up to 60 seconds stale"
Allows consumers to decide if their feature can tolerate this SLO
Consumer constraint
"callers must tolerate stale profile data"
Makes the downstream impact explicit — surfaces breaking changes early
Common caching trade-off vocabulary:
Cache hit rate: percentage of reads served from cache — target >90% for meaningful latency reduction
Cache invalidation: removing or updating stale entries when the source data changes
TTL (Time to Live): the maximum staleness window; how long a cached value is considered valid
Write-through vs. write-behind: whether the cache is updated synchronously (write-through) or asynchronously (write-behind) on writes
Cache stampede / thundering herd: when many concurrent requests simultaneously miss a cold cache and hammer the origin
5 / 10
An architect says: "The system scales horizontally but not vertically." What does this distinction mean, and which architectural property typically enables horizontal but not vertical scaling?
Scaling vocabulary — horizontal vs. vertical:
These are two of the most fundamental and frequently misused terms in architecture discussions. Option A is the correct definition and correctly links stateless, shared-nothing architecture to horizontal scalability.
Hardware ceiling; downtime for resize; diminishing returns
Architecture properties that enable horizontal scaling:
Stateless services: no in-process session state means any instance can serve any request
Shared-nothing architecture: each node operates independently with no shared mutable state in memory
Externalised state: sessions, caches, and user data stored in external systems (Redis, database) — not in the service instance
Architecture review phrases:
"The service is stateless — we can scale horizontally by adding instances behind the load balancer with zero application changes."
"The bottleneck here is the stateful session store, which can't be horizontally scaled without a shared cache layer — that's our single point of vertical pressure."
6 / 10
Sarah (Senior Backend Engineer) sends a Slack message to the team: 'Just deployed the new user authentication service. Initial metrics show a 20% increase in response times, but we've reduced auth failures by 15%. Feels like a good trade-off, right?' Which of the following best captures Sarah's communication regarding this architectural decision?
Sarah's statement is a reasonable initial assessment. However, simply stating 'a good trade-off' isn't sufficient. The key here is recognizing that response time increases *are* a concern, even if failures are reduced. A more detailed explanation would have highlighted the need to monitor this latency increase closely and understand its potential impact on other services.
7 / 10
Mark (Lead Developer) is writing a PR description for changes to the payment processing microservice. He includes the following: 'Implemented a queuing system to handle high transaction volumes. This allows us to process payments asynchronously, improving throughput but introducing potential delays in confirmation notifications.' Which of these best illustrates Mark's understanding of the core trade-off?
Mark correctly identifies the trade-off between throughput (processing many payments quickly) and confirmation notifications. The queuing system inherently introduces delays because it's asynchronous; this is a crucial point to communicate clearly when describing architectural decisions – prioritizing speed over immediate feedback.
8 / 10
David (DevOps Engineer) is explaining the database schema design to a new team member. He says: 'We've created a denormalized read replica of the user profile data. It's updated whenever a write happens, but it's not always perfectly synchronized with the primary database.' Which term best describes this approach?
David's explanation accurately describes eventual consistency. The key phrase 'not always perfectly synchronized' immediately signals that there will be a delay between updates on the primary and the read replica. This is a common trade-off for improved read performance – sacrificing immediate consistency for faster reads.
9 / 10
Emily (Software Architect) is presenting to stakeholders about the decision to use GraphQL instead of REST APIs for the new mobile application. She states: 'GraphQL allows us to fetch only the data a client needs, reducing over-fetching and improving performance on mobile devices – but it introduces increased complexity in our backend architecture.' Which aspect does Emily primarily highlight as part of this trade-off?
Emily correctly identifies that GraphQL's benefit – reduced over-fetching – translates into a lower server load. This is the core trade-off: improved client performance (less data transfer) comes at the cost of increased complexity in the backend architecture and query processing.
10 / 10
John (Senior Developer) is discussing a system design with his team. He says: 'We're building this service to be horizontally scalable – we can add more instances as demand increases. However, scaling *up* vertically (increasing the resources of a single instance) isn't an option due to hardware limitations.' What does John primarily mean by this distinction?
John's statement clearly distinguishes between the two approaches. Horizontal scaling (adding machines) is fundamentally different from vertical scaling (increasing the resources of one machine). The key advantage of horizontal scaling lies in its flexibility and ability to handle increased load by distributing it across multiple instances – a critical architectural consideration when dealing with unpredictable demand.
What will I learn from the "Trade-Off Communication — Software Architecture Exercises" exercise?
Practice English for communicating architectural trade-offs: CQRS framing, precise trade-off statements, explaining eventual consistency, caching trade-offs, and horizontal vs. vertical scaling vocabulary. 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.