Chapter 36 — Security architecture and engineering: performance and scale

Lesson map

Lesson 36 published. Map, example, EX106.

flowchart TD
  N0["Learning outcomes"]
  N1["36.1 The cost of controls"]
  N2["36.2 Token bucket sizing"]
  N3["Lab — Token bucket burst handling"]
  N4["36.3 Designing for scale"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX106"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["36.1 The cost of controls"]
  N2["36.2 Token bucket sizing"]
  N3["Lab — Token bucket burst handling"]
  N4["36.3 Designing for scale"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX106"]

[Learning outcomes]
    |
    v
[36.1 The cost of controls]
    |
    v
[36.2 Token bucket sizing]
    |
    v
[Lab — Token bucket burst handling]
    |
    v
[36.3 Designing for scale]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX106]

Learning outcomes

You will (1) analyse the performance cost of security controls; (2) size rate limiting with a token bucket; (3) design controls that scale with demand.

36.1 The cost of controls

Every control consumes resources. TLS handshakes cost CPU; signature verification adds latency per record; logging consumes storage and network bandwidth; deep inspection slows traffic. At small scale these costs are invisible, but account-based ticketing will process millions of taps per day. Sofia measures the cost of each control in a lab and estimates totals at peak. She finds that signature verification is cheap per record but adds up, while verbose debug logging would exceed storage budgets within weeks. Measuring costs early prevents later pressure to switch controls off when performance suffers.

36.2 Token bucket sizing

The partner gateway from chapter 34 must limit request rates without blocking legitimate bursts, such as many ticket purchases before a concert. Sofia models a token bucket: tokens refill at a steady rate, each request consumes one, and the bucket's capacity allows short bursts. The lab below simulates a synthetic burst of requests against two bucket sizes with the same refill rate. The small bucket rejects many legitimate requests during the burst; the larger one absorbs nearly all of it while still capping sustained abuse. Sizing comes from observed traffic, not guesswork.

Lab — Token bucket burst handling

# Token bucket vs synthetic burst: 20 req/s refill, burst of 300 requests over 5 s.
def run(capacity, refill=20.0, seconds=20):
    tokens, rejected = capacity, 0
    for t in range(seconds):
        tokens = min(capacity, tokens + refill)
        demand = 60 if 5 <= t < 10 else 10
        ok = min(demand, int(tokens)); tokens -= ok; rejected += demand - ok
    return rejected
for cap in (20, 200):
    print(f"capacity {cap:3d}: rejected {run(cap)} of {5*60 + 15*10} requests")

Run with python3 lab_bucket.py. Verified output:

capacity  20: rejected 200 of 450 requests
capacity 200: rejected 20 of 450 requests

36.3 Designing for scale

Controls that work for one server may not scale. A central authorisation service called for every tap becomes a bottleneck and a single point of failure. Sofia proposes caching authorisation decisions with short lifetimes, distributing verification to ingestion nodes with shared public keys and partitioning logs by time and region. Each change keeps the security property while improving scale, and each introduces a new consideration, such as how quickly cached decisions reflect revocations. She documents these trade-offs so operations staff understand why, for example, a revoked partner token may work for up to a minute.

Worked example

Sofia measures control costs, sizes a token bucket for concert bursts and redesigns authorisation and logging to scale while documenting cache-related revocation delays.

Synthetic case. Traffic, costs and bucket parameters are synthetic.

Errors and limits

Lab measurements may not reflect production hardware. Caches create windows where revoked rights still work.

Exercises

• EX106 — Hidden cost. Which control would exceed storage budgets within weeks?
  Show marking criteria

  Rubric: 3 = verbose debug logging;; 2 = logging;; 1 = TLS;; 0 = none.
• EX107 — Bucket comparison. How did the two bucket sizes handle the synthetic burst?
  Show marking criteria

  Rubric: 3 = capacity 20 rejected 200 of 450; capacity 200 rejected 20;; 2 = both;; 1 = same;; 0 = none.
• EX108 — Cache trade-off. What trade-off does caching authorisation decisions introduce?
  Show marking criteria

  Rubric: 3 = revoked rights may keep working until the cache expires;; 2 = revocation delay;; 1 = vague;; 0 = none.

Synthesis

Scalable security measures control costs, sizes limits from real traffic and documents the trade-offs of distributing controls.

Continue studying — chapter 36 of 50

← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →