Chapter 6 — Calculus II
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Exponential growth"]
N2["6.2 Decay"]
N3["6.3 Queues"]
N4["6.4 Series approximations"]
N5["6.5 Sensitivity"]
N6["6.6 Security link"]
N7["Checking with data"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Exponential growth"]
N2["6.2 Decay"]
N3["6.3 Queues"]
N4["6.4 Series approximations"]
N5["6.5 Sensitivity"]
N6["6.6 Security link"]
N7["Checking with data"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Exponential growth]
|
v
[6.2 Decay]
|
v
[6.3 Queues]
|
v
[6.4 Series approximations]
|
v
[6.5 Sensitivity]
|
v
[6.6 Security link]
|
v
[Checking with data]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) model growth and decay in cloud systems with exponential functions; (2) use series for approximations; (3) analyse queue build-up; (4) apply models to capacity and backlog.
6.1 Exponential growth
If meterhub's number of meters grows 3% a month, the count after n months is N0 × 1.03^n. In two years it roughly doubles. Planning capacity on linear assumptions would leave the platform short.
Starting from 80,000 meters, 3% monthly growth gives about 114,000 after a year and roughly 163,000 after two. A linear plan adding 2,400 meters a month, the first month's increase, would predict only about 137,600 at two years, leaving a gap of some 25,000 meters' worth of ingest capacity. Elena puts both curves on one chart so Solent's managers can see where the plans diverge and when.
6.2 Decay
Old log data loses value over time and storage costs accumulate; retention policies model value decaying while cost grows linearly. The crossing point suggests how long to keep detailed logs.
Detailed request logs are most useful in the days after an event, when incidents are investigated; months later they are rarely read, yet each month kept adds to the storage bill. Plotting falling value against rising cumulative cost shows where keeping more stops paying off. Summaries can be kept longer than raw detail, so value is not lost entirely when the detailed copy expires.
6.3 Queues
If readings arrive faster than they are processed, the backlog grows at the difference of the rates. Integrating the difference over an evening peak gives the backlog size, which sets queue capacity.
In the evening, meters report while households cook and heat, so arrivals exceed processing for a while and the queue grows. After the peak, processing catches up and the queue drains. Integrating the excess gives the largest backlog, and the queue must hold at least that many readings, plus a margin, or readings will be dropped at the busiest time.
6.4 Series approximations
For small rates, (1 + r)^n ≈ 1 + nr, a quick estimate. Engineers use such approximations to check whether a detailed model's answer is plausible.
For a 2% rise over five months, the shortcut gives 10% and the exact figure is about 10.4%, close enough to confirm a spreadsheet is sane. Over thirty months the shortcut says 60% while the true growth is about 81%, so the approximation is only for quick checks, never for the final plan. Elena uses it to catch typing mistakes in her capacity model.
6.5 Sensitivity
Derivatives of a model with respect to its inputs show which assumptions matter most. For backlog, the processing rate matters more than the arrival rate near saturation.
Near saturation, a small drop in processing speed sends the backlog climbing steeply, while a similar change in arrivals has a gentler effect. This tells Elena where to spend effort: making ingest pods faster or adding one more replica has a bigger payoff than trying to smooth meter reporting times. Sensitivity also shows which estimates need the most careful measurement.
6.6 Security link
Security events also accumulate: unreviewed alerts, unrotated keys. Modelling backlogs shows when manual processes will fall behind.
If twenty keys need rotating each month but the team only manages fifteen, the overdue count grows by five every month and never recovers on its own. The same arithmetic applies to unreviewed alerts or pending access requests. Seeing the growth early justifies automating rotation or adding time, before the backlog becomes an audit finding or a breach. Elena charts the overdue count monthly.
Checking with data
Elena compares her growth model with twelve months of synthetic meter counts. The model fits within 4%, which gives confidence for planning the next year. Where it diverges, in a month when a new housing estate joined, she notes that step changes need separate planning.
Worked example
Elena models the evening peak: arrivals of 1,500 readings per second for two hours against processing of 1,200 per second. The backlog reaches about 2.2 million readings, which the current queue cannot hold. The team raises processing capacity rather than queue size, because a long queue also delays fraud and tamper alerts.
Synthetic case. Rates are synthetic.
Errors and limits
Models simplify; real arrivals are bursty, so add margin.
Exercises
- EX016 — Doubling. How does 3% monthly growth behave over two years? Rubric: 3 = roughly doubles; 2 = partial; 1 = vague; 0 = none.
- EX017 — Backlog. What was the evening backlog? Rubric: 3 = about 2.2 million; 2 = partial; 1 = vague; 0 = none.
- EX018 — Decision. Why raise processing not queue size? Rubric: 3 = long queue delays alerts; 2 = partial; 1 = vague; 0 = none.
Synthesis
Growth and queue models show when systems and processes fall behind.
Continue studying — chapter 06 of 50
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →