Wave 2 batch 2c: mermaid in 019, 025, 026, 033

shiningflash · shiningflash · commit f1cc61fdc778 · 2026-06-03T02:21:08.000+02:00
019 Same Query Different Answers, ordered triage checklist as
      a mermaid flow with the most likely cause in red.
  025 Smart Meter to Monthly Bill PDF, end-to-end flow from meter
      raw to PDF delivery, showing sealed-bill immutability.
  026 Delivery Idle Driver Tracking, Kafka -&gt; Flink -&gt; Redis -&gt; dispatch
      architecture, plus the driver state machine as a real state
      diagram (login, on_trip, break).
  033 Executive Needs a Number Tomorrow, CAC summary as a markdown
      table instead of an ASCII grid.

  018, 029, 030, 031, 032, 034 had no ASCII art to convert, only
  SQL code blocks. Left as is.
diff --git a/problems/019-same-query-different-answers/solution.md b/problems/019-same-query-different-answers/solution.md
@@ -6,15 +6,28 @@
 
 ### My mental order of checks
 
+```mermaid
+flowchart TB
+    A([1. Time zone difference?])
+    B([2. Row-level security / filtered views?])
+    C([3. Late-arriving rows? Snapshot timing?])
+    D([4. Are you really reading the same table?])
+    E([5. Session settings, date format, locale?])
+    F([6. Collation, case sensitivity, trim?])
+    G([7. Materialized views or aggregated layers?])
+
+    A --> B --> C --> D --> E --> F --> G
+
+    style A fill:#fecaca,stroke:#b91c1c,color:#7f1d1d
+    style B fill:#fed7aa,stroke:#c2410c,color:#7c2d12
+    style C fill:#fed7aa,stroke:#c2410c,color:#7c2d12
+    style D fill:#fef3c7,stroke:#a16207,color:#713f12
+    style E fill:#fef3c7,stroke:#a16207,color:#713f12
+    style F fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
+    style G fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
 ```
-1. Time zone difference?     ← starts here most often
-2. Row-level security / views the user can see?
-3. Late-arriving rows: when was each snapshot taken?
-4. Are you really reading the same table?
-5. Session settings (date format, locale, NULLs ordering)?
-6. Collation / case sensitivity / trim differences?
-7. Materialized views or aggregated layers?
-```
+
+About 90% of the time it's one of the first three.
 
 Let me walk through each.
 
diff --git a/problems/025-smart-meter-to-monthly-bill-pdf/solution.md b/problems/025-smart-meter-to-monthly-bill-pdf/solution.md
@@ -2,48 +2,23 @@
 
 ### The whole flow at a glance
 
-```
-   ┌──────────────────────────┐
-   │ Meter readings (15-min)  │
-   │ s3://meter-raw/...       │
-   └────────────┬─────────────┘
-                │ parser, validation
-                ▼
-   ┌──────────────────────────┐
-   │ Curated 15-min fact      │   (reads_15min, partitioned by date)
-   └────────────┬─────────────┘
-                │
-                ▼
-   ┌──────────────────────────────────────────────┐
-   │  Billing calc job                            │
-   │  (runs once per customer per billing period) │
-   │                                              │
-   │  Inputs:                                     │
-   │   - reads_15min for the period               │
-   │   - tariffs (SCD2)                           │
-   │   - customers (dim)                          │
-   │   - account_adjustments                      │
-   │                                              │
-   │  Output: one bill row + bill_lines           │
-   └────────────┬─────────────────────────────────┘
-                │
-                ▼
-   ┌──────────────────────────┐
-   │  bills (sealed)          │   immutable once issued
-   │  bill_lines              │
-   └────────────┬─────────────┘
-                │
-                ▼
-   ┌──────────────────────────┐
-   │  PDF rendering service   │   pure function of bill_id
-   │  (deterministic)         │
-   └────────────┬─────────────┘
-                │
-                ▼
-   ┌──────────────────────────┐
-   │  Customer portal +       │
-   │  email delivery          │
-   └──────────────────────────┘
+```mermaid
+flowchart TB
+    M([Meter readings, 15-min<br/>s3://meter-raw/...])
+    C([Curated 15-min fact<br/>reads_15min<br/>partitioned by date])
+    B([Billing calc job<br/>per customer per period<br/>uses reads_15min + tariffs (SCD2)<br/>+ customers + adjustments])
+    S([bills (sealed) + bill_lines<br/>immutable once issued])
+    P([PDF rendering service<br/>deterministic, pure function of bill_id])
+    D([Customer portal + email delivery])
+
+    M --> C --> B --> S --> P --> D
+
+    style M fill:#fef3c7,stroke:#a16207,color:#713f12
+    style C fill:#fef3c7,stroke:#a16207,color:#713f12
+    style B fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
+    style S fill:#fed7aa,stroke:#c2410c,color:#7c2d12
+    style P fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
+    style D fill:#dcfce7,stroke:#15803d,color:#14532d
 ```
 
 The principle: each step is a function of the layer beneath it. Re-run the same step on the same inputs and you get the same output. The PDF is the last and least interesting step.
diff --git a/problems/026-delivery-idle-driver-tracking/solution.md b/problems/026-delivery-idle-driver-tracking/solution.md
@@ -2,69 +2,46 @@
 
 ### The shape of the system
 
-```
-Driver app                          Trip system
-sends ping every 5 sec              emits trip events
-  │                                   │
-  ▼                                   ▼
- ─────────────────────────────────────────────
-                 Kafka
-   ┌─────────────┐    ┌──────────────────┐
-   │ driver_ping │    │ trip_status      │
-   │ topic       │    │ topic            │
-   └──────┬──────┘    └────────┬─────────┘
-          │                    │
-          └────────┬───────────┘
-                   ▼
-   ┌────────────────────────────────────────┐
-   │  Stream processor (Flink)              │
-   │                                        │
-   │  Keyed by driver_id, holds the state:  │
-   │    online | on_trip | break | offline  │
-   │  Updated by pings + trip events.       │
-   │                                        │
-   │  For idle drivers, emits to            │
-   │  the "idle drivers" store keyed by H3. │
-   └────────────────┬───────────────────────┘
-                    │
-                    ▼
-   ┌─────────────────────────────────────────┐
-   │  Live driver store                      │
-   │   Redis / DragonflyDB / Aerospike       │
-   │                                         │
-   │   Per-driver hash: { state, lat, lng,   │
-   │                       h3, last_ping }   │
-   │   TTL: 60 sec (auto-expire stale)       │
-   │                                         │
-   │   Index: H3 -> set of driver_ids        │
-   └────────────────┬────────────────────────┘
-                    │
-                    ▼
-   ┌─────────────────────────────────────────┐
-   │  Dispatch service                       │
-   │  Query: "idle drivers within 1.5 km     │
-   │  of (lat, lng)"                         │
-   │  → resolves to hex + neighbors,         │
-   │    reads sets, returns up to N drivers  │
-   └─────────────────────────────────────────┘
+```mermaid
+flowchart TB
+    DA([Driver app<br/>ping every 5s])
+    TR([Trip system<br/>trip events])
+    KP([Kafka: driver_ping])
+    KT([Kafka: trip_status])
+    FL([Flink stream processor<br/>keyed by driver_id<br/>state: online / on_trip / break / offline<br/>emits idle drivers keyed by H3])
+    STORE([Live driver store<br/>Redis / DragonflyDB<br/>per-driver hash with TTL 60s<br/>H3 index to driver set])
+    DISP([Dispatch service<br/>query: idle drivers within 1.5 km<br/>resolves to hex + neighbors])
+
+    DA --> KP --> FL
+    TR --> KT --> FL
+    FL --> STORE --> DISP
+
+    style DA fill:#dcfce7,stroke:#15803d,color:#14532d
+    style TR fill:#dcfce7,stroke:#15803d,color:#14532d
+    style KP fill:#fed7aa,stroke:#c2410c,color:#7c2d12
+    style KT fill:#fed7aa,stroke:#c2410c,color:#7c2d12
+    style FL fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
+    style STORE fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
+    style DISP fill:#fed7aa,stroke:#c2410c,color:#7c2d12
 ```
 
 ### The driver state machine
 
-Drivers move between a few states:
-
-```
-       login         start_trip
-offline ────▶ online ────────▶ on_trip
-   ▲           ▲ ▲              │
-   │           │ │  end_trip    │
-   │   logout  │ └──────────────┘
-   └───────────┘
-               break_start ┌─▶ break ─┐ break_end
-                           │          ▼
-                           └─── back to online
+Drivers move between four states:
+
+```mermaid
+stateDiagram-v2
+    [*] --> offline
+    offline --> online: login
+    online --> offline: logout
+    online --> on_trip: start_trip
+    on_trip --> online: end_trip
+    online --> break: break_start
+    break --> online: break_end
 ```
 
+Only `online` is idle.
+
 Only `online` is idle. The stream processor maintains this state per driver from two streams:
 
 * `driver_ping` (every 5 sec, with location, app says "online or break")
diff --git a/problems/033-executive-needs-a-number-tomorrow/solution.md b/problems/033-executive-needs-a-number-tomorrow/solution.md
@@ -22,17 +22,14 @@ Most of the time, "directional tonight" is the answer. The exec needs a number t
 
 One number per channel, plus a comparison metric they'll want next.
 
-```
-Channel        CAC last quarter   vs last year
-─────────────────────────────────────────────
-Paid Search          $42                +12%
-Social               $61                +18%
-Affiliate            $28                -4%
-Referral             $9                 +2%
-Organic              $3                 -1%
-                  ─────────
-Blended              $34                +9%
-```
+| Channel | CAC last quarter | vs last year |
+| --- | ---: | ---: |
+| Paid Search | $42 | +12% |
+| Social | $61 | +18% |
+| Affiliate | $28 | -4% |
+| Referral | $9 | +2% |
+| Organic | $3 | -1% |
+| **Blended** | **$34** | **+9%** |
 
 The "vs last year" is unsolicited but always asked next. Saves the second round.
 
