AR1: Thinking like an architect: quality attributes and trade-offs
Rough numbers before designs
🎯You'll be able to
Work out rough capacity figures (requests a second, concurrent requests, storage) from business figures, and use them to rule designs in or out.
🏠The everyday picture
Before booking a wedding hall, you count guests. You don't need the exact number, but 80 and 800 need different halls.
📘What it really is
-
Back-of-the-envelope estimates turn business figures into technical ones: orders a day into requests a second, records into storage.
-
Peak, not average: RasoiRoute's peak is 180 orders a minute, which is 3 a second, and messages peak at 540 a minute, or 9 a second.
-
Little's law: requests in progress = arrival rate × time each takes. At 3 orders a second taking 2 seconds each, about 6 are in progress at once.
-
Waiting multiplies: if each order waits 4 seconds for an SMS, 3 a second means 12 orders stuck at once; at 10 seconds, 30.
- Round and say so. These are estimates to choose between designs, labelled as estimates, not promises.
📝A worked example
Input: 180 orders a minute at peak; each order sends 3 messages; the SMS provider sometimes takes 10 seconds.
Steps:
- 180 ÷ 60 = 3 orders a second; 540 ÷ 60 = 9 messages a second.
- If the order waits for its message: in-progress orders = 3 × 10 = 30 at a slow moment, each holding memory and a connection.
- If the message is handed over and the order doesn't wait: in-progress orders = 3 × 0.5 = 1.5 (with a 500 ms deadline).
- Conclusion: not waiting for messaging matters more than adding servers.
Expected output: two figures (30 against 1.5 in progress) that support isolating notifications.
🌍Where it's used
- Capacity planning before sales and festivals in shops and delivery apps.
- Choosing databases: whether data fits on one machine for years or needs splitting.
- Cost estimates for cloud hosting, from requests and storage.
📝Case scenario
A team planned a cluster of servers for a new booking app. A rough estimate showed peak load was 20 requests a second, which one small server handles easily. They launched with two servers for safety and saved months of work; the estimate was labelled and checked after launch.
🖱️Try it
From data/peak-day.csv, find the busiest five minutes and work out the orders a second and the in-progress orders if each took 2
seconds. Success: you show the steps, and round sensibly.
⚠️Common mistakes
- Using averages. Sign: "about 40 orders a minute" for capacity. Fix: plan for the peak.
- False precision. Sign: "2.87 servers". Fix: round, and label the figure as an estimate.
- Skipping the estimate. Sign: a design chosen before anyone counted. Fix: count first; it often rules options out.
🛠️For your project
Project 1's Context includes the peak orders and messages a minute (test 2), which you can turn into the figures above.
✅Quick check
What does Little's law say?
Show the answer
Requests in progress = arrival rate × time each request takes.
Why plan for the peak rather than the average?
Show the answer
Systems fail at the busiest moment, when most customers are affected.