My progress
Menu

Software Architect / Tech Lead · Focus area 1: High-level design

AR1: Thinking like an architect: quality attributes and trade-offs

Goal: explain what an architect is responsible for, describe a system by its quality attributes, make trade-offs openly, draw a system at the right level of detail, and work out rough capacity figures before choosing a design.

You'll need: Module 43 (Backend Architecture), Module 91 (Introduction to System Design), Module 92 (Architecture Patterns), Module 95 (Scaling), Module 96 (Reliability Engineering), and the RasoiRoute practice kit (data/, npm run deps).

Where this is used: a bank deciding how its payments platform should grow, a ride-hailing company planning for festival peaks, a school app deciding whether to build or buy messaging. In each, someone has to say what matters most, what it will cost and what the team won't get.

How it differs: a senior developer makes one feature excellent. An architect shapes how all the features fit together and how the teams that build them work, and spends more time on decisions and their reasons than on code.

Time: reading about 2½ hours · practice (the Try it tasks) about 2 hours · assignment about 3 hours.

Lessons

  1. 1What architects doReading 15–25 minutes, plus practice✓
  2. 2Quality attributesReading 15–25 minutes, plus practice✓
  3. 3Trade-offsReading 15–25 minutes, plus practice✓
  4. 4Drawing and reading a systemReading 15–25 minutes, plus practice✓
  5. 5Rough numbers before designsReading 15–25 minutes, plus practice✓

🛠️Assignment: Describe RasoiRoute as an architect would

  1. Draw RasoiRoute's Context and Container diagrams, with every box and line labelled.
  2. Run npm run deps on the starter and record the dependencies, internal reaches and cycle.
  3. Write four ranked quality attributes, each as a measurable scenario, using the figures in data/.
  4. Work out the peak orders and messages a second, and the in-progress orders with and without waiting for messages.
  5. Write one trade-off statement for isolating notifications, with gain, cost, reason and mitigations.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How does an architect decide what matters for a system before choosing a design?

Show a good answer

A good answer mentions: decisions that are expensive to undo and affect many teams; quality attributes written as measurable scenarios and ranked; availability in nines and parts in a chain multiplying; trade-offs stated with gain, cost and reason, including consistency against availability and simplicity as a quality; C4 diagrams at the right level for the reader, checked against a dependency report from the code; and rough capacity figures from peak load and Little's law, labelled as estimates.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. Which of these is most clearly an architecture decision for RasoiRoute?

Why each option is right or wrong

  • “Renaming the priceItems function so that its name matches the team's wording” (Incorrect): A rename is cheap to undo and stays inside one module.
  • “Choosing the colour of the kitchen managers' daily report heading” (Incorrect): A visual detail, easy to change.
  • “The order in which the unit tests for the invoices module are written” (Incorrect): That's a working habit inside one module, not a structural choice.
  • “Whether reports may read the orders module's private records directly” is correct.

    It is cheap today but makes every later change to orders risky, across teams.

    • Test: expensive to undo, affects many.
    • Record: in an ADR.

📖 Revise: Lesson 1: What architects do

Question ID sp-architect-01-q1 · Report a mistake in this question
2. A logistics start-up lets each developer pick a database per feature. Two years later it runs five. What was missing?

Why each option is right or wrong

  • “Better databases, as the five chosen were probably the wrong products” (Incorrect): Each choice may have been fine on its own.
  • “More developers, so that someone could look after each database” (Incorrect): Adding people doesn't fix the lack of an overall decision.
  • “A rule that only one developer may write code each month” (Incorrect): That would stop the work, not guide it.
  • “Someone looking at the whole system and recording shared decisions” is correct.

    Local choices added up to a costly whole because nobody owned the architecture.

    • Fix: a recorded decision on where data lives.

📖 Revise: Lesson 1: What architects do

Question ID sp-architect-01-q2 · Report a mistake in this question
3. Which is the best way to state a performance need for RasoiRoute?

Why each option is right or wrong

  • “"The ordering system should be fast and scalable for all customers."” (Incorrect): Adjectives can't be tested or compared.
  • “"Ordering should be as fast as the biggest delivery apps in India."” (Incorrect): That's a comparison with no measure or load.
  • “"Servers should have the latest processors and plenty of memory."” (Incorrect): That's a solution, not a need.
  • “"At 180 orders a minute, 95% of order requests answer within 800 ms."” is correct.

    A scenario with a load and a measure can be tested.

    • Also: say what happens when a part is slow.

📖 Revise: Lesson 2: Quality attributes

Question ID sp-architect-01-q3 · Report a mistake in this question
4. Placing an order needs two parts, each available 99.9% of the time. Roughly how available is ordering?

Why each option is right or wrong

  • “99.9%, as the system is only as good as its best part” (Incorrect): Both are needed, so either failing stops an order.
  • “99.99%, as two parts back each other up and make it stronger” (Incorrect): That applies to copies that can stand in for each other, not a chain.
  • “199.8%, adding the two parts' availability together” (Incorrect): Availability can't exceed 100%; chained parts multiply.
  • “About 99.8%, as both must be working at the same time” is correct.

    0.999 × 0.999 ≈ 0.998: parts in a chain multiply.

    • So: fewer parts in the critical path help.

📖 Revise: Lesson 2: Quality attributes

Question ID sp-architect-01-q4 · Report a mistake in this question
5. During a network split between two copies of a bank's balance data, what does the CAP idea say?

Why each option is right or wrong

  • “The system can stay fully consistent and fully available during the split” (Incorrect): During a split it has to give up one of them.
  • “The system should switch to a faster network until the split passes” (Incorrect): The point is what to do while the copies can't talk.
  • “Nothing, as CAP only applies to systems with more than three copies” (Incorrect): It applies to any distributed system with copies.
  • “It must refuse some requests until copies agree, or answer and risk a stale balance” is correct.

    That's the choice between consistency and availability; banks usually choose consistency for balances.

    • Elsewhere: latency against consistency.

📖 Revise: Lesson 3: Trade-offs

Question ID sp-architect-01-q5 · Report a mistake in this question
6. A proposal to split RasoiRoute lists six benefits and no costs. What should an architect ask for first?

Why each option is right or wrong

  • “More benefits, so that the case for splitting becomes even stronger” (Incorrect): More benefits don't make the hidden costs go away.
  • “A list of famous companies that have split their systems the same way” (Incorrect): Other companies' answers don't fit RasoiRoute's figures.
  • “A start date, as the benefits are clear enough to begin the work now” (Incorrect): Starting before the costs are known risks an expensive mistake.
  • “What it gives up, and why those costs are acceptable for this company” is correct.

    A trade-off without its cost can't be judged.

    • Then: mitigations for each cost.

📖 Revise: Lesson 3: Trade-offs

Question ID sp-architect-01-q6 · Report a mistake in this question
7. A school platform's diagram shows three separate services, but fee receipts broke when the students team changed a column. Why?

Why each option is right or wrong

  • “The diagram was drawn at the wrong C4 level for the reader” (Incorrect): The level wasn't the problem; the diagram didn't match the code.
  • “Fee receipts depend on the colour scheme of the student pages” (Incorrect): Nothing suggests a visual link.
  • “Column changes break every system, so no design could have helped” (Incorrect): A clear boundary would have kept the change inside the students service.
  • “The fees code read the students database, unlike the diagram” is correct.

    The real dependency was in the code; a dependency report would have shown it.

    • Fix: fees asks the students service, not its database.

📖 Revise: Lesson 4: Drawing and reading a system

Question ID sp-architect-01-q7 · Report a mistake in this question
8. npm run deps on the RasoiRoute starter shows reports/index.js requires '../orders/store'. What does this mean?

Why each option is right or wrong

  • “Reports uses orders through its front door, as it should do” (Incorrect): The front door is orders/index.js; store is private.
  • “Orders depends on reports and needs to be changed first” (Incorrect): The arrow points from reports to orders.
  • “Nothing, as the dependency report counts only files in tests” (Incorrect): It reads the modules' own code.
  • “Reports reaches inside orders, so changes there may break it” is correct.

    It's an internal reach: private records used from outside.

    • Fix: ask orders.listOrders().

📖 Revise: Lesson 4: Drawing and reading a system

Question ID sp-architect-01-q8 · Report a mistake in this question
9. At peak, RasoiRoute takes 3 orders a second. If each order waits 10 seconds for an SMS, about how many orders are in progress at once?

Why each option is right or wrong

  • “3, the number of orders that arrive each second” (Incorrect): That's the arrival rate, not the number in progress.
  • “13, adding the arrival rate to the waiting time” (Incorrect): Little's law multiplies them.
  • “180, the number of orders that arrive in a whole minute” (Incorrect): That's a minute of arrivals; most of them have finished.
  • “30, as Little's law multiplies arrivals by the time” is correct.

    3 a second × 10 seconds = 30 orders held at once.

    • Compare: 1.5 with a 500 ms deadline.

📖 Revise: Lesson 5: Rough numbers before designs

Question ID sp-architect-01-q9 · Report a mistake in this question
10. A team wants to plan servers from an average of 40 orders a minute. What's the main problem?

Why each option is right or wrong

  • “Averages are too precise, as capacity is better guessed” (Incorrect): Estimates should be rough, but from the right figure.
  • “Servers should be planned from the number of engineers on the team” (Incorrect): Team size doesn't measure customer load.
  • “Order counts can't be turned into requests a second at all” (Incorrect): They can: divide by 60, at peak.
  • “Systems fail at peak, so capacity should be planned from the busiest minutes” is correct.

    RasoiRoute's peak is 180 a minute, more than four times the average.

    • Also: label it as an estimate.

📖 Revise: Lesson 5: Rough numbers before designs

Question ID sp-architect-01-q10 · Report a mistake in this question

ProLearners Assist