حل آموزشی تمرین‌های فصل 2Chapter 2 exercise solutions, explained

• Day = 86400 s; peak factor 10 is a teaching assumption, not a measured trace.
• One order event ≈ 1 KB payload (teaching size); notification delivery is at-least-once.
• The cache holds order-summary rows keyed by order_id in k logical destinations; physical replication costs are counted separately.

Dividing daily orders by seconds/day converts orders/day to orders/s; multiplying by three gives notification rate only. Cache destination count k is independent, so added writes are λ×k. The cache break-even inequality subtracts the with-cache cost from the without-cache cost; use one unit such as CPU-ms/s or currency/s. Doubling k doubles maintenance cost even with unchanged notifications.

1. Rates first 2,000,000 ÷ 86,400 ≈ 23.1 orders/s average, ≈ 231.5 at a 10x peak. Always keep the pair together.
2. Then the workflow fan-out Each order makes 3 internal messages: ≈ 69.4 average, ≈ 694/s at peak. At the teaching payload of 1 KB, peak ≈ 0.7 MB/s — one ordinary queue handles it.
3. Define the view before counting Now define the view: order-summary rows keyed by order id in k destinations (e.g. 2 regions × 2 replicas, k=4). Each order adds exactly k extra writes — not 3.
4. Apply the break-even rule Decision inequality: materialize when (reads/s × value of one faster read) exceeds (orders/s × k × cost of one write); otherwise read-through with a short TTL.

Average: 2,000,000 / 86,400 = 23.15 orders/s. Peak (10x): 231.5/s. Notifications: ≈ 69.4/s average, ≈ 694.4/s peak. At a teaching payload of 1 KB, peak traffic ≈ 0.7 MB/s — one partitioned queue handles it.

View with k = 4: each order adds 4 cache writes (≈ 926/s at peak). If the view serves 5,000 reads/s saving an 8 ms DB read each, the saved work dwarfs the extra writes. At 5 reads/s, materialization loses — serve read-through. Same arithmetic, opposite verdict.

• Read-through cache with short TTL: no extra writes at all, first read after expiry pays one DB fetch. Better when reads are rare or data changes constantly.

Run: javac LoadDemo.java && java LoadDemo — stdlib Java only, instant.

Expected output: avg 23.15, peak 231.5, peak notifications 694.4 (0.68 MB/s), peak extra writes 926 (k=4); busy view MATERIALIZE, quiet view READ-THROUGH; OK. (actual output of this environment)

• Saying '3 services = 3 cache writes'. Notifications go to service queues; cache writes go to view destinations. Different k, different cost, different freshness contract.
• Quoting only the average (23/s) and sizing for it. Capacity, queues and latency budgets must absorb the stated peak (231/s) plus headroom.

• Thresholds (300 ms, 99.9%, 30-day window) are teaching assumptions; real ones come from user-tolerance studies and business cost.
• Timeout = 1 s per attempt; dependency = inventory/risk read behind the status call.
• Alerts must route to an action (rollback, shed load, fail open) — a chart with no action is wallpaper.

Derive thresholds from user needs. For a teaching end-to-end target of three seconds, a provisional budget might be 0.5s network + 0.5s rendering + 1s queue + 0.7s dependency + 0.3s service. This allocation is an assumption requiring traces and user validation. This answer uses 300ms for the service, not the whole journey. Component percentiles do not add into an end-to-end percentile; measure the entire request.

At 50M requests, (1−0.999)×50M=50k allowed failures: a request count, not downtime minutes. Thirty days spans several weekly cycles. Under uniform traffic, consuming 2% of budget in one hour or 10% in six hours implies burn rates 14.4 and 12: budget fraction consumed divided by the time fraction of 720 hours. Variable traffic requires actual error rates and window volumes. Raising the goal to 99.99% shrinks the failure budget tenfold, requiring another cost assessment.

Why three seconds itself? Without user evidence there is no empirical justification; it is a scenario input only. Measure abandonment, repeated requests and satisfaction by latency band, then choose acceptable delay and reduction cost with the product owner. Dividing a three-second budget does not justify choosing that target; it only allocates an already accepted target.

1. Numerators first Write each SLI's numerator and denominator: latency = successful reads under 300ms ÷ all successful reads; availability = non-error responses ÷ all requests. Window: rolling 30 days.
2. Draw the failure lines Define semantic success separately from speed: a correct, acceptably fresh 2xx succeeds; slow successes degrade latency. One-second timeouts and dependency failures fail availability and are excluded from conditional latency. A latency chart alone is therefore insufficient.
3. Budget and its consequence Budget: at 99.9% SLO over the teaching 50M requests, 50,000 failures are allowed. Zero policy: freeze non-critical releases + reliability work only.
4. Two burn speeds, two actions Alerts: fast-burn (2% of budget in 1h → page and rollback) and slow-burn (10% in 6h → ticket). Every alert connects to a runbook action.
5. Split SLO from SLA SLO/SLA split: e.g. contractual SLA 99.5% monthly with 10% credit — looser than the SLO so a normal bad week never pays money.

Teaching volume: 50M status reads / 30 days (≈ 19/s). SLO 99.9% → budget = 0.001 × 50M = 50,000 allowed failures. Fast-burn page: 2% (1,000) within 1 hour. Slow-burn ticket: 10% (5,000) within 6 hours. Latency SLO: 99% of successful reads under 300 ms → at most 1% slow reads, tracked as its own SLI.

• Availability-first: accept slightly stale reads from any replica during a partition when the product tolerates it — e.g. last-known status with an 'updated Xs ago' label. Cost: explicit staleness UX and a freshness metric you must monitor.

• Dependency outage: status reads fail too unless a degraded path serves last-known status with an explicit staleness label — decide in advance which failures may propagate.
• Budget exhausted on day 10 of 30: freeze non-critical releases, spend headroom only on reliability work. A budget with no consequences is decoration.

Run: javac SloBudget.java && java SloBudget — stdlib Java only, instant. Tune requests and slo to your window.

Expected output: allowed failures: 50,000; page threshold 1,000/h; ticket threshold 5,000/6h; OK. (actual output of this environment)

• One number for everything ('99.9% fast and available'). Latency and availability are independent SLIs — a fast error is still an error, a slow success still breaches latency.
• Dashboards nobody acts on. Every chart needs an alert threshold and a runbook action.

• Three AZs in one region; each handles full peak in this conservative design. This exceeds minimum N+1 capacity and carries extra cost.
• Order write ≈ 231/s peak (from exercise 1); RPO ≤ 1 min and RTO ≤ 5 min are teaching targets.
• Clients retry with backoff and idempotency keys.

Three AZs allow a two-of-three majority after losing one AZ, but do not cover regional failure. Giving each AZ full peak capacity is conservative and costs more than minimum N+1. Three-AZ capacity after one failure needs roughly peak/2 per AZ plus operational margin. One-minute RPO bounds accepted data loss; five-minute RTO bounds outage duration. Verify both through separate failover and restore exercises.

1. List every SPOF List every SPOF: API instance, LB, DNS record, single DB primary, single-copy queue, deploy pipeline, on-call human. Separate data plane from control plane and state from stateless.
2. Scale the stateless tier Scale the stateless tier: session-free API behind the LB over 3 AZs with health checks; each AZ alone carries the full peak (N+1).
3. Durable state Make state durable: primary + sync standby + async replica; replicated queue with checkpoints; outbox in the same order transaction. The old primary is epoch-fenced.
4. Separate HA, backup, DR Separate HA from backup and DR: sync standby = HA (seconds); snapshot + WAL = backup with drilled RPO/RTO; second region = DR.
5. Release and roll back Release and roll back: expand–migrate–contract for schema; old and new binaries coexist; rollback means routing back while old columns still exist.

Write path: client → LB (health-checked) → any API instance → DB primary (sync standby ACK) → outbox row in the same transaction → queue → 3 consumers. Read path: status reads from API cache or async replica with a stated lag; never from the primary on the hot path. Keys: orders keyed by order id; queue partitioned by order id so one order's events stay ordered. Health: LB removes unready instances; DB failover promotes the sync standby (fenced old primary); queue consumers checkpoint offsets.

• Queue-first intake: accept the order into a durable queue and confirm asynchronously. Better when peaks are extreme and the product tolerates 'received, processing' states. Cost: a pending state you must explain, track and reconcile — pending money must always be accounted for.

• AZ loss: LB drains it, survivors absorb peak (that is what N+1 was bought for); DB standby in a surviving AZ is promoted, old primary fenced with an epoch token so split-brain writes are rejected.
• Rolling-upgrade clash: old binary writes schema v1 while new expects v2. Expand–migrate–contract forbids it: v1+v2 coexist, both binaries run, backfill, then contract. Rollback = route back while v1 columns still exist.
• Poison queue message: one malformed order kills the consumer in a loop. Dead-letter queue + per-message retry cap + alert; the path stays up while the poison is inspected offline.

Run: javac FailoverDemo.java && java FailoverDemo — stdlib Java only, instant.

Expected output: survivors 463 vs peak 231.5 -> ABSORBED; primary now AZ-c at epoch 8; old primary fenced; stale write REJECTED, fresh write ACCEPTED; OK. (actual output of this environment)

• 'Two machines, no SPOF.' The load balancer, DNS, single DB primary, deploy pipeline and on-call human are all still single points until each is doubled or shown unnecessary.
• Confusing HA with backup. Standby serving in seconds is HA; last night's snapshot restoring in an hour is backup (RPO/RTO); a second region is DR.