Estimate, Evaluate and Balance
DabbaGo's order confirmations slow down every lunch peak. The team has three ideas: a bigger database server, a queue that accepts orders instantly and confirms them later, or splitting orders into its own service. Each engineer defends a favourite. The architect's job is not to have the best opinion. It is to put numbers on the problem, compare the options fairly, and say clearly what each one gives up.
The rule
Every gain costs something; estimate, weigh, then choose the cost you can afford.
The rule holds three skills.
Estimate with rough numbers. Architects need the right order of magnitude, not a precise figure. DabbaGo gets about 3,000 orders in its busiest ten minutes. That is 3,000 ÷ 600 seconds, about 5 orders a second. A single well-tuned database handles far more than that, so if orders are slow the cause is probably slow queries, not raw volume. A rough estimate often changes the whole conversation.
Evaluate against weighted attributes. Score each option on the quality attributes that matter, weighted by how much they matter to this business right now:
| Attribute (weight) | Bigger server | Queue | Separate service |
|---|---|---|---|
| Speed at peak (3) | 2 | 3 | 2 |
| Simplicity (3) | 3 | 2 | 1 |
| Cost (2) | 2 | 2 | 1 |
| Weighted total | 19 | 19 | 11 |
Scores run from 1 (poor) to 3 (good). The table does not decide for you; it makes the argument visible. Here two options tie, which tells you the weights deserve a closer look.
Balance the trade-off. Quality attributes pull against each other. The queue makes placing an order faster but means the customer waits for a separate confirmation, and it adds a component that can fail. More security often means more friction for users. Lower cost often means less spare capacity. There is no option without a cost, only options whose costs you can accept.
The shortcut
Run Size, Score, Sacrifice: size the problem with a rough number, score the options against weighted attributes, then name the sacrifice of the winner in one sentence.
Size
About 5 orders a second at peak. That is modest, so volume alone is not the problem. Profiling shows two slow report queries hitting the same database at noon.
The trap is presenting an option as having no downside. When someone says "there is no trade-off", the cost has simply not been found yet.
Drills
Answer fast — trust the rule.
DabbaGo expects 6,000 orders in its busiest ten minutes after the Mumbai launch. Roughly how many orders a second is that?
What is a weighted scoring table for?
Adding a queue lets customers place orders faster. What is a real cost it brings?
An engineer says their proposal "has no trade-offs at all". What does the rule suggest?
Remember
- Every gain costs something: estimate, weigh, then choose the cost you can afford.
- Shortcut: Size, Score, Sacrifice.
- Trap: believing any option comes with no downside.