Interactive systems lab / 04

Capacity Planner Lab.

Turn a product shape into a resource plan. Change a single assumption and watch its effect carry through the system.

Linked estimates

Start with people. Follow the load.

First move: Lower cache hit rate on the current product. Watch database operations change while peak traffic stays the same.

Product shapes

Peak traffic156/s

DB operations64/s

Connections199 spare

Full results ↓

Set the assumptions

Daily active users

Distinct users active on an average day.

Requests per user per day28

Peak multiplier4×

Traffic at the busy hour relative to the daily mean.

Requests per instance400/s

Target utilisation70%

Read share82%

Cache hit rate72%

Advanced assumptions

Indexed reads per DB node / s

Writes per DB node / s

Hot objects per active user

Hot working-set fraction30%

Cached object size (KB)

Stored write size (KB)

Read response size (KB)

Storage replication factor

Retention (years)

DB pool per app instance

Worker/admin DB reserve

Database connection limit

DAU120K

Peak traffic156/s

App instances2

DB nodes*1

Demand

120K people × 28 requests = 3.4M requests/day.

38.9 average / s156 peak / s

Average = requests/day ÷ 86,400. Peak = average × 4.

Application fleet

At 400/s per instance and 70% target use, plan 1 busy + 1 spare.

2 instances280 budget / instance

The spare is a simple failure/deploy allowance, not an availability guarantee.

Cache → database

Explore cache behaviour ↗

128 reads/s and 28 writes/s reach the app. Cache absorbs 92 reads/s; the database receives the misses plus writes.

Cache hits 92/sDB reads 36/sWrites 28/s

Without cache, DB reads would be 128/s. With this hit rate, DB operations equal about 41% of peak requests.

Database shape*

1 write partition and 0 read replicas per partition under this simplified budget.

64 DB ops / s1 estimated nodes

*Independent read/write throughput ceilings. No join cost, lock contention, replica lag, or cross-shard transactions.

Connection budget

2 instances × 8 connections + 35 reserved = 51 / 250.

199 connections remain. This is a configured ceiling, not observed simultaneous use.

Footprint over time

Hot cache0.5 GBDAU × objects/user × hot fraction × object KB

Stored per year1,325 GBAverage writes × size × replication

At retention3,974 GB3 years of accumulated writes

Peak read egress12 MbpsBefore CDN, compression, and protocol overhead

What changes the architecture?

This workload fits the simplified single-database budget. Measure real query plans and load before adding distributed components.

All sizes use decimal KB/GB. Throughput constants are editable assumptions, not universal hardware ratings. The planner ignores variance within a minute, background jobs beyond the connection reserve, failover topology, bandwidth pricing, and service-specific latency.

Under the model

Estimates make assumptions testable.

DAU alone does not set capacity. Requests per user and peak concentration produce traffic. Instance throughput and headroom set a fleet estimate. Read share and cache hit rate change database demand. The configured pool size and maximum instances create a connection ceiling even when the average request is cheap.

Use the result to find questions for a load test. Hardware throughput, query mix, provider limits, replica lag, and failure behaviour must be measured in a real system before a deployment plan is accepted.

Set cache hit rate to zero and inspect database reads.
Raise peak multiplier; watch both instances and connection budget.
Change write size and retention to see storage compound.

Lesson 04 / Check your understanding

Can you explain the result?

Ten app instances each allow 20 DB connections. Workers reserve 30. Can a 150-connection database cover the configured ceiling?

Your turn

Choose one answer