Capstone: Compare Two Architecture Options

By the end of this lesson, you will be able to...

• Write a short architecture comparison that identifies components, properties, evidence, and constraints.

• Use relative clauses, modifiers, comparatives, superlatives, equality, and degree language in one coherent design note.

• Make a conditional recommendation that states both the benefit and the cost of the chosen option.

• Review your own wording for hidden scope, unsupported certainty, and ambiguous comparison targets.

Idea in one sentence: A good architecture comparison lets the reader reconstruct the system, the evidence, and the decision boundary from the sentences alone.

Core Insight

Consider a payment service that must send a receipt after a successful charge. The team is choosing between two architecture options:

• Option A: direct API adapter. The payment service calls the receipt provider on the request path.
• Option B: queue worker. The payment service publishes a receipt job, and a worker delivers it with independent retries.

The first draft of the design note says:

The queue solution is better and safer. It is slower but the API is simple. We only changed the client and it is the best option.

The note contains real observations, but the reader cannot tell which it refers to, what safer means, what is slower, or which candidates the best compares. The capstone is to turn this draft into a bounded architecture comparison.

You are not trying to make Option A or Option B sound impressive. You are trying to make the decision inspectable.

The Evidence Pack

The team runs both options in the same canary workload:

The product requirement is to acknowledge a payment quickly. The reliability requirement is that a receipt-provider timeout must not make the client retry the payment charge. The operations requirement is to keep the first launch easy to roll back.

The evidence creates a real trade-off:

• The direct adapter is faster on the median path and simpler to launch.
• The queue worker has a higher median latency, but its p95 is lower in this canary and its receipt retries are isolated from payment retries.
• The worker requires more components and rollback steps.

No single adjective can express all three requirements honestly.

The Capstone Deliverable

Write a design note of 180–250 words. It should contain:

1. a short context sentence that names the payment path;
2. one sentence that identifies each option or component with a clause;
3. at least two bounded comparisons;
4. one equality or inequality sentence if the evidence supports it;
5. one too, enough, so, or such sentence that connects a degree to a constraint or consequence;
6. one sentence with a focus or frequency modifier such as only, still, already, usually, or rarely;
7. a conditional recommendation with a visible trade-off;
8. a final uncertainty or follow-up sentence if the canary does not prove a universal claim.

The note should be short enough for a design review and detailed enough for a reader who did not attend the meeting.

Build the Note Step by Step

Step 1: Name the promise and the system

Start with the user-visible action:

The payment service sends a receipt after the charge succeeds.

This sentence gives the rest of the comparison a stable subject. Avoid opening with This solution when two solutions are about to appear.

Step 2: Identify each option with a clause

Use a relative clause to keep the architecture map visible:

Option A is the direct adapter, which calls the receipt provider on the payment path.
Option B is the queue worker, which accepts a receipt job and retries delivery separately.

The clauses add information about already named options. If the reader must select one option from a larger set, use a defining clause instead:

The worker that owns receipt retries runs outside the payment request.

Choose commas according to the information boundary, not according to sentence length.

Step 3: State the pairwise performance comparison

Use a comparative with a metric and workload:

The direct adapter is faster than the queue worker on median receipt latency in the canary.

The target is visible, and on median receipt latency in the canary prevents faster from becoming a claim about every measure.

Step 4: State the resilience comparison

Use a comparative or superlative for the failure condition:

The queue worker is more resilient than the adapter during receipt-provider timeouts.

If a third option had been tested, a superlative could rank one member of the set. Here there are two options, so more resilient than is the natural form.

Step 5: Include equality only when it is real

The data does not show equal median latency, so do not invent an as...as sentence for latency. It does support a more careful equality about deployment count only if the counts match; here they do not. An acceptable inequality is:

The queue worker is not as simple to deploy as the direct adapter because it has four components instead of two.

The form is useful because it keeps the reference pair visible while naming the evidence.

Step 6: Connect a degree to a constraint

Use too or enough when a number meets or crosses a requirement:

The worker's 240 ms median is still low enough for the 500 ms acknowledgment budget.

This sentence does not claim that the worker is fast in every context. It says that its measured latency meets this particular budget.

Alternatively, describe the consequence of a degree:

The provider timeout is so disruptive on the direct path that the client can retry the payment request.

The consequence explains why retry isolation matters.

Step 7: Place a focus modifier

Use only or still to make the requirement precise:

Only the queue worker retries a receipt after the provider timeout.
The payment service still needs a clear acknowledgment path before it can switch designs.

The first sentence limits the component that performs the retry. The second keeps an unresolved requirement visible.

Step 8: Recommend conditionally

Tie the option to the requirement and state its cost:

Choose the queue worker when retry isolation is the priority, despite its higher median latency and extra rollback steps. Choose the direct adapter for a low-risk launch when the simpler operational surface matters more than independent receipt retries.

This is not indecision. It is a decision rule that another engineer can apply when the constraints change.

One Possible Completed Note

Here is one model answer. It is not the only correct answer; use it to inspect the structure.

The payment service sends a receipt after the charge succeeds. Option A is the direct adapter, which calls the receipt provider on the payment path. Option B is the queue worker, which accepts a receipt job and retries delivery separately. The direct adapter is faster than the queue worker on median receipt latency in the canary, but the worker is more resilient during provider timeouts and has a lower p95 in this sample. The queue worker is not as simple to deploy as the adapter because it has four components instead of two. Its 240 ms median is still low enough for the 500 ms acknowledgment budget, while the provider timeout is so disruptive on the direct path that the client can retry the payment request. Only the queue worker retries a receipt independently. Choose the worker when retry isolation is the priority, despite its higher median latency and extra rollback steps. Choose the adapter for a low-risk launch when the smaller operational surface matters more. The canary does not establish which option is safest for every workload, so we still need a failure test with real provider timeouts.

Notice the sequence:

1. The first sentence establishes the promise.
2. The relative clauses identify the two options and their jobs.
3. Comparatives name latency and resilience with boundaries.
4. Not as simple as connects the design cost to component count.
5. Enough and so...that connect measured degrees to requirements and consequences.
6. Only identifies the retry owner.
7. The recommendation is conditional and includes costs.
8. The final sentence preserves uncertainty and names the next test.

The note is detailed, but every sentence changes the reader's decision map. Remove any sentence that only repeats an adjective.

Self-Review Checklist

Before submitting your note, read it once as an engineer who missed the design meeting.

Reference and clause check

• Can you identify what every which, that, it, and this refers to?
• Does each relative clause select an option or add information about an already named option?
• Are commas showing the intended information boundary?

Comparison check

• Does every faster, safer, best, or as...as sentence name its property?
• Is the comparison target or candidate set visible?
• Are both sides measured under the same workload and time window?

Modifier and degree check

• Does only limit the intended subject, action, or object?
• Does still preserve an unresolved requirement rather than add vague emphasis?
• Does too identify a blocked action, and does enough identify a met requirement?
• Are slightly, much, usually, or `rarely supported by evidence?

Decision check

• Does the recommendation say when to choose the option?
• Does it state what the option costs?
• Does it distinguish a measured result from a hypothesis?
• Does it name a follow-up test where the evidence is incomplete?

If a sentence fails one check, repair that sentence instead of adding more adjectives to the paragraph.

Common Capstone Mistakes

Mistake: comparing architecture names instead of properties

The worker is better than the adapter.

Repair it:

The worker is more resilient during provider timeouts, while the adapter is faster on median latency.

Mistake: using a superlative with two options

The worker is the safest than the adapter.

Repair it:

The worker is safer than the adapter during provider timeouts.

Mistake: turning one metric into a universal claim

The adapter is the best because its median is lower.

Repair it:

The adapter has lower median latency, but the worker has better retry isolation and a lower p95 in this canary.

Mistake: hiding the requirement in too or enough

The worker is fast enough.

Repair it:

The worker is fast enough for the 500 ms acknowledgment budget in the canary.

Mistake: using only without a scope

We only changed the client.

If the intended meaning is that no other component changed, write:

Only the client changed in this rollout.

If the intended meaning is that the change was limited to configuration, write:

We changed only the client configuration.

The capstone is successful when the reader does not have to guess which interpretation you intended.

Change One Constraint, Recalculate the Language

The recommendation should respond when the requirement changes. Suppose product reduces the acknowledgment budget from 500 ms to 250 ms. The queue worker's 240 ms median still fits that budget, but its p95 remains 310 ms. The note should not simply repeat fast enough:

The queue worker is fast enough for the 250 ms median acknowledgment budget, but its p95 is above the target in the current canary.

The design may still be acceptable if the acknowledgment uses the enqueue event rather than receipt delivery. If that contract changes, the comparison changes too:

The worker is not as fast as the adapter for a receipt that must arrive before the client responds.

This is why a conditional recommendation is more durable than the worker is best. The grammar exposes the condition that makes the recommendation true.

Now change the failure requirement. Suppose the receipt provider has a history of five-minute outages. The direct adapter's request path is now more exposed to provider timeouts:

The direct adapter is too coupled to the provider timeout for a payment path that must avoid duplicate charges.

The queue worker is not magically safe, however. It still needs idempotency, a visible job state, and a policy for exhausted retries. Keep the claim bounded:

The queue worker is safer for isolating receipt retries during a five-minute provider outage, provided that the receipt job is idempotent.

The final provided that condition belongs in the design note because it changes the risk. The comparison language cannot replace the architecture mechanism; it makes the mechanism and its boundary easier to inspect.

A Shorter Version for a Status Update

The full capstone note may be too long for a daily update. Compress it only after the scope is clear:

The adapter is faster and simpler to launch, while the queue worker isolates receipt retries and has a lower p95 in the canary. We recommend the worker for provider-outage resilience despite its extra components; the adapter remains suitable when median latency and rollback simplicity dominate.

This shorter version keeps four essentials: the two options, one benefit per option, the boundary (in the canary), and a conditional recommendation. It omits the relative clauses and detailed metrics because the linked design note already defines them. Compression is safe when the reference is available; it is risky when the sentence stands alone.

If the update is read without that context, restore the nouns:

The direct API adapter is faster on median receipt latency, while the queue-worker architecture isolates retries during provider outages.

The repeated nouns are not waste. They prevent a reader from attaching faster to the wrong component after a paragraph break.

Final Editing Pass

Read the note once without looking at the grammar labels. Mark every sentence that contains an adjective or adverb. For each mark, ask whether the reader can answer three questions: compared with what, under which condition, and with what consequence? If one answer is missing, add a noun, metric, workload, or requirement. Then read only the verbs and their modifiers. Check that only names the intended owner, still marks unfinished work, and already marks completed work without implying approval. Finally, remove universal words such as always, never, or best unless the evidence really supports them. Replace them with a count, a time window, or a conditional phrase. This pass turns a grammatically correct note into one that another engineer can safely use.

If the reader still asks “what exactly is faster?” or “safer under which failure?”, the note is not finished. A good capstone makes those questions answerable before the review meeting begins. That clarity is the final engineering deliverable, not merely a language exercise. The reader should leave with a choice, a reason, a limit, and a next test.

Assessment Rubric

Score each category from 0 to 2:

A score of 9 or more is a strong first draft. A lower score does not mean the architecture decision is wrong; it shows where the English hides the reasoning. Revise the lowest-scoring category first.

Daily Practice Lines

• The direct adapter is faster on median latency, but the queue worker is more resilient during provider timeouts.
• Only the queue worker retries a receipt independently.
• Choose the worker when retry isolation matters, despite its higher operational cost.

These lines reuse the track's core habits: name the property, place the modifier, and attach the recommendation to a requirement.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Relative clauses and comparison - Focus: combine identifying clauses, modifiers, and comparison forms in clear sentences.
• [ARTICLE] Microsoft Writing Style Guide: Grammar - Focus: make architecture claims concrete, scoped, and actionable.

Key Takeaways

• A capstone comparison should let a reader reconstruct the system and the decision boundary.
• Use clauses to identify responsibilities, modifiers to control scope, and comparisons to state one property at a time.
• Tie too, enough, so, and such to a real threshold or consequence.
• A recommendation is stronger when it states the condition under which it applies and the cost it accepts.
• Preserve uncertainty when a canary or benchmark does not prove a universal architecture claim.