Skip to main content
  1. System Design Components/

Role-Based Scaling Bottleneck And Mitigation Phrase Sheet

Role-Based Scaling Bottleneck And Mitigation Phrase Sheet #

Status: Archive candidate. Keep as historical reference; prefer system-design-core-index.md and the core notes for day-to-day use.

Phrase-sheet derivative; not part of the primary framework.

Use this to generate scaling bottlenecks systematically instead of memorizing system-specific hotspot lists.

The method:

  1. classify the component role
  2. run the role’s bottleneck phrases
  3. instantiate them in domain language
  4. pair each with one mitigation phrase
  5. instantiate the mitigation in domain language

Use the causal phrase when thinking. Use the anchor in brackets when speaking in interviews.


Core Table #

RoleBottleneck PhrasesMitigation Phrases
Truthmany actors touch the same row [hot key], one decision point serializes writes [serialization point], one read path serves everyone [read hotspot], every commit must be copied [replication cost], one query walks too much truth [broad scan]split the truth boundary [shard/split], avoid central serialization [partition ownership], cache near reads [cache/read replica], narrow commit scope [smaller atomic unit], precompute alternate access path [index/projection]
Derivedone source event updates too many outputs [fanout], updates arrive faster than projection catches up [projection lag], one popular view attracts too many reads [hot projection], rebuild recomputes too much history [rebuild cost], one query merges too many partial results [scatter-gather]project asynchronously with buffering [queue/buffer], reduce write amplification [hybrid push-pull], partition projection keys [shard projection], bound rebuild scope [incremental rebuild], pre-aggregate before merge [hierarchical aggregation]
Coordinationtoo many workers ask one coordinator for permission [fan-in], ownership must be refreshed too often [heartbeat storm], everyone waits for one sequencer [single sequencer], failures cause retries together [retry storm], expired ownership clears too slowly [slow reclamation]decentralize decisions [local claim/partitioned coordination], lengthen or batch renewals [lease tuning/batching], split coordinator by subject [partition sequencer], backoff and jitter retries [jitter/backoff], sweep and reclaim aggressively [reaper/sweeper]
Immutabletoo much data must be published at once [publish bandwidth], too many readers fetch the same object [read amplification], too many requests go through one reference point [hot head/manifest], integrity or existence is checked too often [validation pressure], cleanup traverses too much history [GC cost]publish by chunks/layers [chunking], cache aggressively at edge [CDN/cache], replicate hot refs or metadata [head caching/replication], cache existence checks [dedup cache], collect by reachability epochs or generations [epoch GC/generational cleanup]
External Effectone dependency answers too slowly [dependency latency], retries multiply original load [retry amplification], downstream accepts less than we send [throttling], unconfirmed effects pile up [reconciliation backlog], buffer grows faster than it drains [queue buildup]isolate with async boundary [outbox/queue], make receiver idempotent [idempotency], rate-shape outbound traffic [rate limit/backpressure], reconcile asynchronously [reconciliation worker], drop or defer noncritical work [load shedding/deprioritization]

Cross-Cutting Modifiers #

These are not component roles. They are workload shapes that cut across roles and explain the bottlenecks the role table does not capture cleanly by itself.

Use them after the role phrases when the bottleneck is about distribution, synchronization, or growth shape rather than one component’s local behavior.

ModifierBottleneck PhrasesMitigation Phrases
Cardinality / Breadthtoo many distinct keys must be tracked [high cardinality], one request touches too many shards or index slices [query breadth], too much metadata exists for rarely used items [long tail]bound key space [cardinality cap], pre-aggregate or tier access paths [hierarchical index/aggregation], move cold state to cheaper tiers [tiering]
Temporal Synchronytoo much work becomes eligible at the same instant [boundary burst], many caches or windows refresh together [thundering herd], many clients reconnect or retry together [synchronized retry/reconnect]spread activation over time [jitter/staggering], warm the next window before cutover [precompute/prewarm], coalesce duplicate refresh or miss traffic [request collapsing]
Distribution Skewcapacity exists but in the wrong bucket [fragmentation/skew], some regions are overloaded while others are idle [hot-zone skew], one shared pool absorbs one tenant’s burst [noisy neighbor]rebalance or repartition by the real contention key [rebalance/repartition], isolate hot tenants or regions [pool isolation], add overflow or fallback paths [spillover/fallback]
Growth / Retentionhistory grows faster than cleanup [retention pressure], rebuild or replay grows linearly with age [history growth], storage footprint grows faster than serving capacity [storage growth]compact or snapshot periodically [compaction/snapshot], expire or downsample older state [TTL/downsample], separate hot and cold storage [hot-cold split]

How the Role Table and Modifiers Work Together #

Use both dimensions together:

  1. role tells you which component is likely to saturate
  2. modifier tells you what load shape is causing the saturation

Examples:

  • Derived + one request touches too many shards or index slices [query breadth]
    • search query fans out broadly across many shards
  • Truth + capacity exists but in the wrong bucket [fragmentation/skew]
    • inventory exists overall but the hot event section is sold out while others are idle
  • Coordination + too much work becomes eligible at the same instant [boundary burst]
    • cron boundary creates a claim storm on one scheduler path
  • Immutable + too much metadata exists for rarely used items [long tail]
    • edge cache metadata pressure from millions of cold objects
  • Truth or Execution paths + one shared pool absorbs one tenant's burst [noisy neighbor]
    • worker pool latency spikes because one tenant monopolizes scarce-capability workers

Example Instantiations #

HoldState #

  • role: Truth + Coordination
  • bottleneck phrase: many actors touch the same row [hot key]
  • mitigation phrase: avoid central serialization [partition ownership] or isolate contention [queue/gate]

Instantiated:

  • bottleneck: many users try to hold the same seat at once
  • mitigation: gate the hot seat/section through a narrow contention path or partition inventory where possible

Feed projection #

  • role: Derived
  • bottleneck phrase: one source event updates too many outputs [fanout]
  • mitigation phrase: reduce write amplification [hybrid push-pull]

Instantiated:

  • bottleneck: one celebrity post fans out to millions of feeds
  • mitigation: push for normal users, pull celebrity content at read time

Config rollout #

  • role: Coordination + Derived
  • bottleneck phrase: too many workers ask one coordinator for permission [fan-in]
  • mitigation phrase: decentralize decisions [local claim/partitioned coordination] or cache distribution [hierarchical distribution]

Instantiated:

  • bottleneck: too many agents poll the control plane for the new version
  • mitigation: publish the new version once and serve snapshots through regional distributors or caches

Blob delivery #

  • role: Immutable
  • bottleneck phrase: too many readers fetch the same object [read amplification]
  • mitigation phrase: cache aggressively at edge [CDN/cache]

Instantiated:

  • bottleneck: many clients download the same artifact from origin
  • mitigation: cache blobs at CDN/edge and replicate hot manifests

Webhook delivery #

  • role: External Effect
  • bottleneck phrase: retries multiply original load [retry amplification]
  • mitigation phrase: rate-shape outbound traffic [rate limit/backpressure]

Instantiated:

  • bottleneck: one provider slowdown causes a webhook retry storm
  • mitigation: queue webhooks, cap retries, and drain at the provider’s acceptance rate

Fast Role Heuristics #

  • Truth

    • authoritative row/object/state machine
    • if overloaded, correctness or commit latency is directly threatened
  • Derived

    • projection, index, cache, dashboard, read model
    • bottlenecks usually appear as lag, fanout, rebuild cost, or read skew
  • Coordination

    • lease, claim, leader, sequencer, placement, ownership
    • bottlenecks usually appear as fan-in, retry storms, or central ordering pressure
  • Immutable

    • version, blob, manifest, artifact, chunk, immutable segment
    • bottlenecks usually appear as publish bandwidth, read amplification, or GC cost
  • External Effect

    • webhook, email, SMS, payment provider, third-party callback
    • bottlenecks usually appear as dependency latency, throttling, or reconciliation backlog

Short Form #

  • Truth -> write/read/commit/replication hotspots
  • Derived -> fanout/lag/rebuild/query hotspots
  • Coordination -> fan-in/renewal/sequencer/retry hotspots
  • Immutable -> publish/read/head/validation/cleanup hotspots
  • External -> dependency/retry/throttle/buffer hotspots

Usage Rule #

Do not start from generic anchor words alone.

Start from the causal phrase:

  • what exactly is happening too much?
  • where is the concentration or amplification?

Then use the bracketed anchor when you need concise interview language.