@shaykec/bridge 0.4.25 → 0.4.26

package/modules/stakeholder-communication/module.yaml

@@ -0,0 +1,38 @@
+slug: stakeholder-communication
+title: "Stakeholder Communication — Status Updates That Actually Help"
+version: 1.0.0
+description: "Write effective status updates, communicate delays, and manage stakeholder expectations with clarity and impact."
+category: project-management
+tags: [stakeholder-communication, status-updates, reporting, project-management, leadership]
+difficulty: beginner
+
+xp:
+  read: 10
+  walkthrough: 30
+  exercise: 20
+  quiz: 15
+  quiz-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 15
+  guided: 40
+
+prerequisites: []
+related: [risk-management, sprint-planning, one-on-ones]
+
+triggers:
+  - "How do I write a good status update?"
+  - "How do I communicate project delays?"
+  - "How do I manage stakeholder expectations?"
+  - "What should I include in a project status report?"
+
+visuals:
+  diagrams: [diagram-flow, diagram-mermaid]
+  quiz-types: [quiz-drag-order, quiz-timed-choice]
+  slides: true
+
+sources:
+  - url: "https://www.amazon.com/Crucial-Conversations-Tools-Talking-Staked/dp/1469266822"
+    label: "Crucial Conversations by Patterson et al."
+    type: book

package/modules/stakeholder-communication/quick-ref.md

@@ -0,0 +1,89 @@
+# Stakeholder Communication Quick Reference
+
+## Pyramid Principle
+
+**Lead with the conclusion.** First line = takeaway. Then support.
+
+## RAG Status
+
+| G | Green — On track |
+|---|-------------------|
+| A | Amber — At risk; working on it |
+| R | Red — Off track; needs intervention |
+
+## Status Update Structure
+
+1. **What happened** — Completed, shipped
+2. **What's next** — Planned
+3. **Blockers** — What's in the way
+4. **Risks** — What might go wrong + mitigation
+
+## Audience Quick Guide
+
+| Audience | Want |
+|----------|------|
+| Executives | Outcomes, timeline, risks, decisions |
+| Engineers | Blockers, dependencies, scope |
+| Product | Priorities, trade-offs |
+| Customers | When, what's new |
+
+## Stakeholder Grid
+
+| | Low Interest | High Interest |
+|---|--------------|----------------|
+| **High Power** | Keep satisfied | Manage closely |
+| **Low Power** | Monitor | Keep informed |
+
+## Bad News Template
+
+1. State the fact
+2. Explain cause
+3. What you're doing
+4. What you need
+5. Next update when
+
+## Status Template (Short)
+
+```
+RAG: [G/A/R] | TL;DR: [One sentence]
+
+Completed: [Bullets]
+Next: [Bullets]
+Blockers: [Blocker + owner]
+Risks: [Risk + mitigation]
+```
+
+## Cadence Examples
+
+| Who | Cadence | Format |
+|-----|---------|--------|
+| Core team | Daily | Standup, Slack |
+| Leads | Weekly | Written + call |
+| Execs | Bi-weekly | Written (pyramid) |
+
+## Written vs Verbal
+
+| Written | Verbal |
+|---------|--------|
+| Status, decisions, specs | Alignment, sensitive topics |
+| Async, record | Real-time, Q&A |
+
+## Mermaid: Stakeholder Grid
+
+```mermaid
+quadrantChart
+  x-axis Low Interest --> High Interest
+  y-axis Low Power --> High Power
+  quadrant-1 Manage closely
+  quadrant-2 Keep informed
+  quadrant-3 Monitor
+  quadrant-4 Keep satisfied
+```
+
+## Avoiding Overload
+
+- 1 page max (exec)
+- Bullets over paragraphs
+- Link to details
+- Consistent format
+- RAG + key points first

package/modules/stakeholder-communication/quiz.md

@@ -0,0 +1,73 @@
+# Stakeholder Communication — Quiz
+
+## Question 1
+
+The pyramid principle suggests you should:
+
+A) Bury the conclusion at the end
+B) Lead with the conclusion, then support it
+C) Use only bullet points
+D) Never mention risks
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: The pyramid principle means putting the most important point first. Busy stakeholders often skim; if they read only the first line, they should get the takeaway. Support with details below. -->
+
+## Question 2
+
+In RAG status, Amber typically means:
+
+A) Everything is perfect
+B) At risk; issues exist; we're working on them
+C) Project is cancelled
+D) No update this week
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Amber = at risk. There are issues, but the team is addressing them. It needs attention but isn't yet Red (off track). Amber is common and appropriate when managing risks. -->
+
+## Question 3
+
+When communicating bad news (e.g., a delay), you should:
+
+A) Wait until you have a full solution
+B) Communicate early, state the fact, explain cause, share plan
+C) Send it only to your manager
+D) Use vague language to soften the blow
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Bad news does not improve with age. Communicate early. Be clear: state the fact, explain why, say what you're doing, and what you need. Early communication creates more options and preserves trust. -->
+
+## Question 4
+
+In a power/interest stakeholder grid, a high-power, high-interest stakeholder should be:
+
+A) Monitored only
+B) Kept satisfied with minimal contact
+C) Managed closely—regular, rich updates
+D) Excluded from updates
+
+<!-- ANSWER: C -->
+<!-- EXPLANATION: High power + high interest = manage closely. They have influence and care. They need regular, substantive updates and involvement in decisions. Keep them informed and engaged. -->
+
+## Question 5
+
+An effective status update structure includes:
+
+A) Only what was completed
+B) What happened, what's next, blockers, risks
+C) Jira ticket IDs and technical details only
+D) A maximum of one sentence
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: A good status answers four questions: What happened? What's next? What are the blockers? What are the risks? This structure gives stakeholders a complete picture without overwhelming them. -->
+
+## Question 6
+
+To avoid information overload in status updates, you should:
+
+A) Include every detail in the main email
+B) Use one page max for exec summaries, bullets over paragraphs, link to details
+C) Send daily 10-page reports
+D) Never use written updates
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Respect your reader's time. One page max for exec summaries. Prefer bullets over paragraphs. Link to detailed docs or tickets rather than inlining everything. Consistent format helps people scan quickly. -->

package/modules/stakeholder-communication/resources.md

@@ -0,0 +1,41 @@
+# Stakeholder Communication — Resources
+
+## Books
+
+- **Crucial Conversations: Tools for Talking When Stakes Are High** by Patterson, Grenny, McMillan, and Switzler — Masterclass on difficult conversations, including delivering bad news and managing expectations.
+- **The Pyramid Principle** by Barbara Minto — The classic on structuring communication: lead with the conclusion.
+- **Never Split the Difference** by Chris Voss — Negotiation and communication from an FBI negotiator; useful for high-stakes stakeholder conversations.
+- **Thanks for the Feedback** by Douglas Stone and Sheila Heen — Receiving and giving feedback; applies to status and reviews.
+
+## Articles and Readings
+
+- [The Pyramid Principle in Practice](https://www.mckinsey.com/~/media/mckinsey/industries/public%20and%20social%20sector/our%20insights/the%20pyramid%20principle%20and%20the%20art%20of%20communicating%20on%20purpose/the-pyramid-principle-in-practice.pdf) — McKinsey. Applying the pyramid principle to business communication.
+- [How to Write a Project Status Update](https://www.atlassian.com/blog/inside-atlassian/how-to-write-project-status-updates) — Atlassian. Templates and best practices.
+- [RAG Status Reporting](https://www.apm.org.uk/resources/find-a-resource/earned-value-management-rag-status-reporting/) — APM. Red/Amber/Green in project management.
+- [Stakeholder Analysis and Mapping](https://www.mindtools.com/pages/article/newPPM_08.htm) — Mind Tools. Power/interest grid and analysis.
+- [Communicating Bad News to Stakeholders](https://www.pmi.org/learning/library/communicating-bad-news-stakeholders-7097) — PMI. Delivering difficult updates.
+
+## Tools
+
+- [Notion](https://www.notion.so/) — Status pages, project wikis, shared updates.
+- [Confluence](https://www.atlassian.com/software/confluence) — Status reports, meeting notes, stakeholder pages.
+- [Jira](https://www.atlassian.com/software/jira) — Status via dashboards, filters, and release reports.
+- [Linear](https://linear.app/) — Cycle updates, project status.
+- [Slack](https://slack.com/) — Async updates, channels per project or stakeholder group.
+- [Loom](https://www.loom.com/) — Short video updates for async stakeholder communication.
+
+## Templates
+
+- [Project Status Report Template](https://www.smartsheet.com/content/project-status-report-templates) — Smartsheet. Free status report templates.
+- [Stakeholder Map Template](https://miro.com/templates/stakeholder-map/) — Miro. Power/interest grid for collaboration.
+- [RAG Status Dashboard](https://www.atlassian.com/software/jira/status) — Jira. Built-in RAG and status tracking.
+
+## Podcasts
+
+- [Manager Tools](https://www.manager-tools.com/) — Communication, feedback, and managing up.
+- [The Look & Sound of Leadership](https://www.manager-tools.com/podcasts/look-sound-leadership) — Executive communication.
+
+## Videos
+
+- [Barbara Minto on the Pyramid Principle](https://www.youtube.com/results?search_query=pyramid+principle+barbara+minto) — Search for Minto's presentations.
+- [Crucial Conversations Summary](https://www.youtube.com/results?search_query=crucial+conversations+summary) — Summaries of the book's key ideas.

package/modules/stakeholder-communication/walkthrough.md

@@ -0,0 +1,74 @@
+# Stakeholder Communication Walkthrough — Learn by Doing
+
+## Before We Begin
+
+**Diagnostic:** Who are you writing for? Think of one person who gets your project updates. What do they *need* from you—and what would they skip? How does your audience change the message?
+
+**Checkpoint:** You can name at least two different audiences for the same project and one way your update would differ for each.
+
+---
+
+## Step 1: Draft a Status Update
+
+**Task:** Pick a project (real or hypothetical). Write a 6–8 line status update using the structure: What happened, What's next, Blockers, Risks. Apply the pyramid principle—lead with the conclusion (RAG + one-sentence TL;DR).
+
+**Question:** If your reader only saw the first line, would they get the right takeaway? What would they miss?
+
+**Checkpoint:** Update has RAG, TL;DR, and all four sections. First line is the conclusion.
+
+---
+
+## Step 2: Map Stakeholders
+
+<!-- hint:buttons type="single" prompt="Who belongs in the 'manage closely' quadrant?" options="High power + high interest,High power + low interest,Low power + high interest,Low power + low interest" -->
+<!-- hint:list style="cards" -->
+
+**Task:** List 5 stakeholders for your project. Plot each on a power/interest grid. For the "manage closely" quadrant, write one sentence: what do they need from your updates?
+
+**Question:** How would your update change if you were writing for the "manage closely" vs "keep informed" quadrant? What would you add or remove?
+
+**Checkpoint:** 5 stakeholders plotted; "manage closely" needs are stated.
+
+---
+
+## Step 3: Communicate a Delay
+
+**Task:** Imagine your release is slipping by 1 week due to a third-party API delay. Write a 4–5 sentence message to an executive. Include: the fact, the cause, what you're doing, and what you need (if anything).
+
+**Question:** What might you be tempted to soften or hide? Why is stating it clearly better?
+
+**Checkpoint:** Message is direct, includes cause and plan, and has a clear ask or next step.
+
+---
+
+## Step 4: Tailor for Two Audiences
+
+**Task:** Take one status update. Create two versions: (1) For an executive—3–4 bullets, pyramid style. (2) For an engineering lead—more detail on technical blockers and dependencies.
+
+**Question:** What's different? What would be wrong with sending the exec version to the eng lead, or vice versa?
+
+**Checkpoint:** Both versions exist; exec version is shorter and outcome-focused; eng version has technical detail.
+
+---
+
+## Step 5: Apply RAG Thoughtfully
+
+<!-- hint:card type="tip" title="RAG status: Red = needs attention, Amber = watch, Green = on track" -->
+
+**Task:** You have: (A) One minor bug in edge case. (B) Key developer out for a week. (C) Scope creep request from stakeholder. Assign RAG to each and justify. Write one sentence for each on how you'd communicate it.
+
+**Question:** When is Amber more appropriate than Red? When might Green be misleading?
+
+**Checkpoint:** RAG assigned with rationale; communication approach stated for each.
+
+---
+
+## Step 6: Design a Cadence
+
+<!-- hint:celebrate -->
+
+**Task:** For your project, define update cadence for: core team, product/eng leads, and executives. Specify: frequency, format (written/call), and what each gets.
+
+**Question:** What happens if executives get daily updates? What happens if they get monthly? Where's the right balance?
+
+**Checkpoint:** Cadence defined for 3 levels; format and content appropriate to each.

package/modules/system-design/content.md

@@ -0,0 +1,149 @@
+# System Design — From Requirements to Architecture
+
+## The System Design Interview Framework
+
+A structured approach to designing scalable systems:
+
+1. **Requirements** — Clarify functional (what) and non-functional (scale, latency, availability)
+2. **Estimation** — Back-of-envelope (DAU, QPS, storage) to bound the problem
+3. **High-level design** — Sketch boxes and arrows (API, services, data flow)
+4. **Deep dive** — Choose 2–3 components to detail (DB schema, caching, bottlenecks)
+5. **Bottlenecks** — Identify single points of failure, scale limits, mitigation
+
+```mermaid
+flowchart LR
+    A[Requirements] --> B[Estimation]
+    B --> C[High-Level Design]
+    C --> D[Deep Dive]
+    D --> E[Bottlenecks]
+```
+
+## CAP Theorem
+
+In a distributed system, you can only guarantee **two of three**:
+
+| Property | Meaning |
+|----------|---------|
+| **Consistency** | Every read returns the latest write |
+| **Availability** | Every request receives a response |
+| **Partition tolerance** | System works despite network failures |
+
+In practice: network partitions happen. You choose **CP** (e.g., banking) or **AP** (e.g., social feeds).
+
+## Architecture: Typical Web App
+
+```mermaid
+flowchart TB
+    subgraph Client
+        C[Client / Browser]
+    end
+    subgraph Edge
+        CDN[CDN / Static Assets]
+    end
+    subgraph App
+        LB[Load Balancer]
+        A1[App Server 1]
+        A2[App Server 2]
+        A3[App Server N]
+    end
+    subgraph Data
+        Cache[Cache Redis/Memcached]
+        DB[(Primary DB)]
+        Replica[(Replica)]
+        MQ[Message Queue]
+    end
+    C --> CDN
+    C --> LB
+    LB --> A1 & A2 & A3
+    A1 & A2 & A3 --> Cache
+    A1 & A2 & A3 --> DB
+    DB --> Replica
+    A1 & A2 & A3 --> MQ
+```
+
+## Load Balancing
+
+Distribute traffic across servers: **Round-robin**, **least connections**, **consistent hashing** (for stateful affinity).
+
+```bash
+# Example: nginx upstream (round-robin)
+upstream app_servers {
+    server 10.0.0.1:3000;
+    server 10.0.0.2:3000;
+    server 10.0.0.3:3000;
+}
+```
+
+## Caching Strategies
+
+| Layer | Use Case | Example |
+|-------|----------|---------|
+| **CDN** | Static assets, edge caching | CloudFront, Cloudflare |
+| **App cache** | Hot data, session | Redis, Memcached |
+| **DB cache** | Query result cache | Redis, query cache |
+
+**Cache-aside:** App checks cache first; on miss, fetches from DB and populates cache. **Write-through:** Write to DB and cache together.
+
+## Database Choices
+
+| Type | When to Use |
+|------|-------------|
+| **SQL** | ACID, relational, complex joins |
+| **NoSQL (document)** | Flexible schema, high write throughput |
+| **NoSQL (key-value)** | Simple lookups, session storage |
+| **NoSQL (columnar)** | Analytics, time-series |
+
+**Sharding:** Partition data by key (e.g., user_id) across DB instances. **Replication:** Read replicas for read scaling; primary for writes.
+
+## Message Queues
+
+Decouple producers and consumers: **RabbitMQ**, **Kafka**, **SQS**. Use for async processing, event sourcing, buffering spikes.
+
+## Microservices vs Monolith
+
+| Monolith | Microservices |
+|----------|---------------|
+| Single deployable unit | Independently deployable services |
+| Simpler ops, shared DB | Per-service DB, network boundaries |
+| Good for small teams | Scales org and team size |
+
+Start with a monolith; extract services when boundaries are clear.
+
+## Rate Limiting
+
+Protect APIs: **token bucket**, **sliding window**, **fixed window**. Return `429 Too Many Requests` with `Retry-After` header.
+
+## Consistent Hashing
+
+Minimize rebalancing when nodes are added/removed. Keys map to a ring; each node owns a range. Used in CDN, caching, sharding.
+
+## Microservices Layout
+
+```mermaid
+flowchart LR
+    subgraph Gateway
+        API[API Gateway]
+    end
+    subgraph Services
+        S1[Auth Service]
+        S2[User Service]
+        S3[Order Service]
+        S4[Payment Service]
+    end
+    subgraph Shared
+        MQ[Message Bus]
+        E[Event Store]
+    end
+    API --> S1 & S2 & S3 & S4
+    S2 & S3 & S4 --> MQ
+    MQ --> E
+    S1 -.-> S2
+    S3 --> S4
+```
+
+## Key Takeaways
+
+- **Requirements first** — Don't over-engineer for scale you don't need
+- **Bottlenecks** — Identify SPOFs and plan for failure
+- **Cache wisely** — Invalidation is hard; design for it
+- **Async where it helps** — Message queues for decoupling and buffering

package/modules/system-design/exercises.md

@@ -0,0 +1,83 @@
+# System Design Exercises
+
+## Exercise 1: Design a News Feed
+
+**Task:** Design a news feed (e.g., Twitter-like) for 10M users. Document: (1) functional and non-functional requirements, (2) data model (users, posts, follows), (3) high-level architecture with cache and DB, (4) how you'd generate "feed for user X" (fan-out on write vs read).
+
+**Validation:**
+- [ ] Requirements are clear and bounded
+- [ ] Data model supports follows and posts
+- [ ] Architecture includes load balancer, app tier, cache, DB
+- [ ] Tradeoffs between fan-out on write vs read are explained
+
+**Hints:**
+1. Fan-out on write: precompute feeds when a post is created; fast reads, slower writes
+2. Fan-out on read: fetch from followed users at read time; simpler writes, heavier reads
+3. Hybrid: fan-out for normal users, on-read for celebrities
+
+---
+
+## Exercise 2: Add Caching to an API
+
+**Task:** You have a REST API: `GET /users/:id` returns user profile. Add a cache layer. Define: (1) cache key format, (2) TTL, (3) invalidation strategy when user updates profile, (4) what to do on cache miss.
+
+**Validation:**
+- [ ] Cache key is deterministic and unique per user
+- [ ] TTL chosen with reasoning (e.g., 5 min vs 1 hour)
+- [ ] Invalidation on write is specified (invalidate key, or write-through)
+- [ ] Cache-aside flow on miss is correct
+
+**Hints:**
+1. Key: `user:{id}` or `user:profile:{id}`
+2. Invalidation: delete key on PUT/PATCH, or use write-through
+3. Cache stampede: consider locking or probabilistic early refresh
+
+---
+
+## Exercise 3: Shard a Database
+
+**Task:** You have a `orders` table with 1B rows. Design a sharding strategy. Specify: (1) shard key, (2) number of shards, (3) how to route a query for "orders by user_id", (4) how to handle "orders by date range" (cross-shard query).
+
+**Validation:**
+- [ ] Shard key chosen (user_id typical for orders)
+- [ ] Routing is deterministic (e.g., hash(user_id) % N)
+- [ ] Cross-shard query strategy described (query each shard, merge; or use a separate analytics DB)
+
+**Hints:**
+1. user_id as shard key: all orders for a user on same shard
+2. date range: either scatter-gather or maintain a read replica for analytics
+3. Consistent hashing helps when adding/removing shards
+
+---
+
+## Exercise 4: Message Queue for Async Jobs
+
+**Task:** Design a "send email" flow: user signs up → send welcome email. Use a message queue. Draw the flow: API → queue → worker. What happens if the worker fails mid-processing? How do you ensure at-least-once delivery?
+
+**Validation:**
+- [ ] Flow is API → enqueue → worker consumes
+- [ ] Failure handling: retry, dead-letter queue
+- [ ] At-least-once: acknowledge only after successful send; redeliver on timeout
+- [ ] Idempotency considered (don't send duplicate emails)
+
+**Hints:**
+1. Worker acks after email sent; if crash before ack, message redelivered
+2. Idempotency: store sent_email_ids or use idempotency key
+3. Dead-letter queue for messages that fail repeatedly
+
+---
+
+## Exercise 5: Rate Limiting Design
+
+**Task:** Implement a simple rate limiter: max 100 requests per minute per API key. Describe the data structure and algorithm. What would you use in Redis? Write pseudocode for "is request allowed?".
+
+**Validation:**
+- [ ] Algorithm chosen (fixed window, sliding window, or token bucket)
+- [ ] Data structure supports per-key counters
+- [ ] Redis INCR + EXPIRE or similar is correctly described
+- [ ] Edge cases: what if the clock is at minute boundary?
+
+**Hints:**
+1. Fixed window: `KEY = "ratelimit:{api_key}:{minute}"`, INCR, EXPIRE 60
+2. Sliding window: sorted set, remove expired, count, add current
+3. Token bucket: more complex but smoother limiting

package/modules/system-design/game.yaml

@@ -0,0 +1,95 @@
+games:
+  - type: scenario
+    title: "Scale the System"
+    startHealth: 5
+    steps:
+      - id: start
+        situation: "You're designing a URL shortener (like bit.ly). It launches and goes viral — traffic spikes 100x in a week. You need a database to store short codes and long URLs. Which do you choose?"
+        choices:
+          - text: "PostgreSQL — ACID guarantees, easy schema, good for relational data."
+            consequence: "PostgreSQL is solid but can become a write bottleneck. For a shortener, you might need horizontal scaling soon."
+            health: 0
+            next: database
+          - text: "Redis — blazing fast, simple key-value. Short code → long URL fits perfectly."
+            consequence: "Redis is great for cache, but persisting to disk and handling durability is trickier. You'd typically use Redis for cache, not primary storage alone."
+            health: -1
+            next: database
+          - text: "PostgreSQL for durability + Redis for hot cache — best of both."
+            consequence: "Smart. Durable storage plus fast reads. You can scale reads with Redis and keep writes in PostgreSQL."
+            health: 1
+            next: database
+      - id: database
+        situation: "Traffic keeps growing. Redis cache expires, and suddenly 10,000 requests hit the database at once for the same popular link. Cache stampede! How do you handle it?"
+        choices:
+          - text: "Let them all hit the database — it can handle it."
+            consequence: "A stampede can overwhelm the DB. You need to prevent thundering herd."
+            health: -2
+            next: stampede
+          - text: "Use probabilistic early expiration — some requests extend TTL, others repopulate cache."
+            consequence: "Probabilistic early expiration (e.g. 'recompute before expire') spreads load. Good pattern."
+            health: 1
+            next: stampede
+          - text: "Implement request coalescing — only one request fetches; others wait for it."
+            consequence: "Request coalescing (or 'single-flight') ensures only one recompute. Others block and get the result. Also valid."
+            health: 1
+            next: stampede
+      - id: stampede
+        situation: "Cache stampede is under control. But global users complain about latency — requests from Asia take 200ms to reach your US datacenter. What next?"
+        choices:
+          - text: "Add more database replicas in the same region."
+            consequence: "Replicas help DB load but don't fix network latency. Users far from the server still wait."
+            health: -1
+            next: cdn
+          - text: "Put a CDN in front — cache short URLs at edge locations worldwide."
+            consequence: "CDN caches at the edge. Most requests never hit your origin. Latency drops dramatically."
+            health: 1
+            next: cdn
+          - text: "Move the entire system to a region closer to most users."
+            consequence: "Single-region migration is disruptive. CDN gives global edge without moving everything."
+            health: 0
+            next: cdn
+      - id: cdn
+        situation: "CDN is live. But one influencer posts a link — suddenly one short code gets 80% of all traffic. Hot key! The cache node for that key is overwhelmed. How do you deal with it?"
+        choices:
+          - text: "Shard the cache by short code — spread hot keys across nodes."
+            consequence: "Sharding by short code can still put a hot key on one node. Hot keys need different handling."
+            health: -1
+            next: hot_key
+          - text: "Replicate the hot key to multiple cache nodes, or use consistent hashing with virtual nodes."
+            consequence: "Replicating hot data or using more granular hashing spreads the load. Good approach."
+            health: 1
+            next: hot_key
+          - text: "Ignore it — CDN should absorb most of it."
+            consequence: "CDN helps, but if the key is so hot it overwhelms a single CDN node, you need a strategy."
+            health: -1
+            next: hot_key
+      - id: hot_key
+        situation: "Hot key is mitigated. Leadership says: prepare for 10x growth in 6 months. What do you prioritize?"
+        choices:
+          - text: "Rewrite everything in a faster language."
+            consequence: "Premature optimization. Architecture and bottlenecks matter more than language for most scale problems."
+            health: -2
+            next: growth
+          - text: "Add read replicas, consider write partitioning (e.g. by short code range), and capacity plan."
+            consequence: "Solid. Scale reads, plan for write partitioning if needed, and model capacity. Pragmatic."
+            health: 1
+            next: growth
+          - text: "Build a real-time analytics dashboard first."
+            consequence: "Analytics are nice but not critical for handling 10x. Core scalability comes first."
+            health: -1
+            next: growth
+      - id: growth
+        situation: "You've scaled the shortener: PostgreSQL + Redis cache, CDN, hot-key handling, and growth plan. A new requirement: track click analytics (timestamp, geo, device) for each short code. How do you add it?"
+        choices:
+          - text: "Add analytics columns to the main URLs table."
+            consequence: "Mixing transactional and analytical data slows both. High-volume analytics bloat the core table."
+            health: -2
+            next: end
+          - text: "Write analytics to a separate high-throughput store (e.g. Kafka + data lake, or append-only store)."
+            consequence: "Right. Separate the analytics pipeline from the core URL lookup. Event stream or append-only keeps the shortener fast."
+            health: 1
+            next: end
+          - text: "Store analytics in Redis and batch-flush to PostgreSQL."
+            consequence: "Redis can buffer, but analytics volume may overwhelm. A dedicated pipeline (Kafka, etc.) is more robust for high volume."
+            health: 0
+            next: end