Path 6 · Module 6
Well-Architected Framework: Performance Efficiency
Read the module on Microsoft Learn, then come back here: test yourself with the quiz and apply it in the design exercise. Write down what you want to remember with the ✎ Note buttons.
Step 1 · Read the module
Open Well-Architected Framework: Performance Efficiency on Microsoft Learn. The units:
- Introduction
- Negotiate realistic performance targets
- Design to meet capacity requirements
- Achieve and sustain performance
- Improve efficiency through optimization
- Summary
Close the Learn tab. Answering from memory is what makes it stick; looking it up just measures how fast you can scroll.
Quiz
20 exam-style questions, roughly in the order of the units. Click an answer to see the explanation. Your best score is saved and shown on the path page; use Retry at the end to go again.
1. What's the first step in the performance efficiency pillar?
D. Targets (e.g. response time, throughput) make performance measurable.
2. Which is a well-defined performance target?
C. Targets are specific, measurable and tied to load.
3. Why use percentiles (p95, p99) instead of averages for response time?
B. Tail latency matters for user experience.
4. What's the difference between scaling up and scaling out?
A. Scale out is usually preferred for elasticity and resilience.
5. What must an application be to scale out easily?
A. Stateless instances can be added and removed freely.
6. Which technique splits data across stores to increase throughput?
B. Partitioning removes a single-store bottleneck.
7. Which pattern reduces load on a database for frequently read, rarely changed data?
C. Caches serve repeat reads with low latency.
8. Users worldwide complain about slow static content. What helps most?
A. Reducing distance reduces latency.
9. Before launch, how do you verify the design can handle expected peak load?
C. Load tests validate capacity and find bottlenecks.
10. What's capacity planning?
C. Plan for growth, peaks and subscription limits.
11. Why consider subscription quotas and service limits in performance design?
A. Request quota increases early and design around limits.
12. Autoscale reacts too slowly to a sale that starts at 09:00 sharp. What do you add?
B. Pre-scale for predictable events.
13. Which practice keeps performance from degrading as the workload evolves?
D. Regressions are caught early when performance is tested routinely.
14. Which tool helps find slow dependencies and code paths in a running app?
A. APM data points to the bottleneck.
15. How should a long-running operation be handled in an HTTP API?
C. Async processing keeps front ends responsive.
16. What does "optimize the hot path" mean?
B. Effort goes where it has the most user impact.
17. A database query is slow. Which optimization should you try before scaling up the database?
C. Fix inefficiency before throwing hardware at it.
18. Which trade-off is common when improving performance?
C. Balance performance against cost, reliability and simplicity.
19. Why choose the region close to users and data?
A. Co-locate compute with users and data.
20. When should you revisit performance targets?
B. Targets evolve with the workload.
Design exercise
On paper · about 25 minutes
Starling Tickets sells festival passes. Normal load is 200 users; when a big festival opens sales, 50,000 users arrive within 10 minutes. The current site (one large App Service instance + SQL Database) times out at about 3,000 users. Most traffic is people refreshing the event page.
-
Task
Set the targets
Write two measurable performance targets with the business.
Done when- Targets use percentiles and load levels.
Model answer
- Event page: p95 < 300 ms at 50,000 concurrent users.
- Checkout: p95 < 1 s at 2,000 checkouts/minute, no lost orders.
-
Task
Design for the peak
Propose the changes and how you'll prove they work.
Done when- Read traffic is offloaded.
- Scaling is pre-planned.
- A test validates it.
Model answer
Front Door/CDN caching for the event page; Redis cache-aside for availability counts; stateless app with scale-out and scheduled pre-scaling before sales open; checkout via a queue (async) to protect the database; virtual waiting room if needed; SQL tuned and scaled (Hyperscale or Business Critical with read replica); quotas checked; Azure Load Testing at 60,000 users in the pipeline before each big sale.