- My Development Notes/
- System Design Components/
- Role-Based Scaling Bottleneck And Mitigation Phrase Sheet/
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:
- classify the component role
- run the role’s bottleneck phrases
- instantiate them in domain language
- pair each with one mitigation phrase
- instantiate the mitigation in domain language
Use the causal phrase when thinking. Use the anchor in brackets when speaking in interviews.
Core Table #
| Role | Bottleneck Phrases | Mitigation Phrases |
|---|---|---|
Truth | many 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] |
Derived | one 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] |
Coordination | too 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] |
Immutable | too 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 Effect | one 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.
| Modifier | Bottleneck Phrases | Mitigation Phrases |
|---|---|---|
Cardinality / Breadth | too 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 Synchrony | too 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 Skew | capacity 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 / Retention | history 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:
roletells you which component is likely to saturatemodifiertells 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
TruthorExecutionpaths +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 hotspotsDerived-> fanout/lag/rebuild/query hotspotsCoordination-> fan-in/renewal/sequencer/retry hotspotsImmutable-> publish/read/head/validation/cleanup hotspotsExternal-> 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.