Trade-Off Communication — Software Architecture Exercises

1 / 5

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 / 5

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
B	"horizontal read scalability", "replication lag", "eventual consistency"	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 / 5

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?

Explaining eventual consistency vocabulary — stakeholder register:

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 / 5

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?

Trade-off statement vocabulary — specificity requirements:

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 / 5

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.

Term	Also called	Mechanism	Limiting factor
Horizontal scaling	Scale out / scale in	Add more nodes; distribute load across instances	Shared state, session affinity, coordination overhead
Vertical scaling	Scale up / scale down	Add more CPU, RAM, or I/O to a single node	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."