DB Olympics

Queries · q133 · VP Platform Engineering · week 1, night 4

Support Tickets: Affected vs Other Tenants, Baseline vs Incident Period

“Was the Nov-Dec ticket rise for the 10 carts.remind-affected tenants a real spike against their own baseline, or just their normal (or seasonal) level?”

Manager · asked the questionDiego MoralesVP Platform Engineering. Former reliability lead at a payments company. Owns uptime and the integrations merchants depend on.
Analyst · planned the reportLucas MoreauPragmatic: answers the question asked with the simplest reliable report.
Engineer · wrote the SQLInesThinks in window functions: ranks, running totals, LAG/LEAD for comparisons, percent-of-total.

Fictional people at a fictional company, each played by a language-model agent. Who they are and what they are told

  1. A business event lands on the VP Platform Engineering's desk

    Week 1; shared with Samuel Whitcombe, Head of Merchant Success

    Leadership wants a review of platform reliability in 2025: failed and slow background jobs, health check failures, rate limiting, webhook delivery problems, and which merchants felt them.

  2. Diego Morales writes to Lucas Moreau

    The manager, at the start of week 1

    Subject: 2025 platform reliability review — what I need by Friday

    Lucas,

    Leadership wants a year-in-review on platform reliability for 2025, and I'm leading it jointly with Samuel Whitcombe (Merchant Success). The deliverable is a memo that tells leadership how reliable the platform actually was last year, where it hurt merchants most, and what that implies for our 2026 investment priorities (reliability engineering headcount, which integrations/carriers to fix or replace, whether we need stricter rate limiting or SLAs). Samuel's side will map our findings to specific merchant relationships and churn risk, so where possible, surface things in a way that can be tied back to individual merchants rather than only platform-wide averages.

    Given you only get a handful of report slots a night, here's what matters most to me, roughly in priority order:

    1. How often did background work actually fail or run late in 2025, and is it getting better or worse? I want a view across the year (not just a single average) so we can see trend, not just a snapshot.
    2. When something broke, which merchants bore the brunt of it? I'd rather see a short list of the merchants hit hardest by job failures, slow jobs, or delivery problems than a platform-wide blended number — that's what Samuel needs to go have conversations.
    3. Were there periods where our own health checks told us something was wrong, and did that line up with the times merchants complained or things failed? I want to know if our monitoring is actually catching problems early or if we're flying blind.
    4. Are merchants getting throttled by our rate limits in ways that look like it's hurting their business, rather than protecting us? I want to know if this is a tuning problem or a capacity problem.
    5. How reliable are our webhook deliveries to merchants' own systems, and are there particular integrations or providers that are chronically troublesome? This feeds a build-vs-fix-vs-drop decision on a couple of integration partners.

    If you have to cut scope to fit your nightly slots, protect #1 and #2 — those are what the memo absolutely must answer. The rest can wait or be addressed at a higher level if time runs short.

    Let me know if anything above is ambiguous before you spend a slot on it.

    Diego

    A note from the Head of Merchant Success, Samuel Whitcombe

    Subject: Platform reliability review — what I need from my side

    Hi Lucas,

    As you pull together the 2025 reliability picture, here's what matters from the merchant-health side:

    1. Did our largest merchants actually feel this? For our top-tier accounts (the ones I sit QBRs with this month), can we tell whether job failures, health check issues, rate limiting or webhook problems clustered on their tenants more than the long tail — and whether it tracked with order volume or came out of nowhere?
    2. Did reliability issues coincide with commercial pain? I'd like to know if the merchants hit hardest by these issues also show signs of strain elsewhere — support tickets spiking, churn or downgrades, slower sales — so I can tell if this is a cause or just a correlation worth flagging.
    3. Any repeat offenders going into 2026? Were there a handful of merchants who got hit repeatedly through the year rather than a one-off bad week platform-wide? I want to walk into January reviews knowing who to proactively address before they raise it.

    Happy to flag specific merchant names if that helps scope the analysis.

    Best, Samuel

  3. Lucas Moreau plans the night

    The analyst · week 1, night 4, request 1 of 3

    Night 3 gave two important, slightly conflicting signals I need to resolve on this final night. First, Report 1 shows the Nov carts.remind incident did hit real top-tier accounts - Cragsley Outfitters, our #1 tenant by 2025 revenue, is among the 10 affected, alongside #4, #6, #7 and #8 - alongside four zero-revenue/zero-order tenants, so it's a mixed bag, not purely long-tail. Second, Report 2's ticket spike for the 10 affected tenants actually starts climbing weeks before the Nov 24 failure and peaks a week after, which could mean real merchant pain preceded our systems detecting it (bad for the 'are we flying blind' question) - but it could also just be that these are naturally higher-ticket (bigger) merchants, or a seasonal Black-Friday/holiday ticket bump everyone gets. I need a baseline comparison to tell those apart before I write that into the memo as a finding. With my last 3 slots I'll: (1) settle the ticket-spike-vs-baseline question properly using an Aug-Sep baseline for affected vs other tenants, so I can honestly say cause vs. coincidence; (2) finally give Diego a first cut at webhook reliability by individual endpoint, since Report 3 showed a flat ~5-6% of deliveries each month never resolve to success or hard failure (stuck retrying) and he explicitly wants to know which integrations are chronically troublesome; (3) check whether that same webhook stuck-rate clusters on the 10 affected tenants vs everyone else, which is exactly Samuel's cross-dimension clustering question for his top-tier accounts.

    Support Tickets: Affected vs Other Tenants, Baseline vs Incident Period
    Question
    Was the Nov-Dec ticket rise for the 10 carts.remind-affected tenants a real spike against their own baseline, or just their normal (or seasonal) level?
    One row per
    tenant group (Affected vs Other), comparing two time periods
    Columns
    • group_name
    • tenant_count
    • avg_weekly_tickets_per_tenant_baseline
    • avg_weekly_tickets_per_tenant_incident
    • pct_change
  4. Ines writes the SQL

    The engineer · 1 dry run on the empty schema, then the submission

    Dry run 1 · STATUS: COMPILES (dry run on the empty schema, no data read)
    WITH affected AS (
      SELECT DISTINCT jr.tenant_id
      FROM job_runs jr
      JOIN jobs j ON jr.job_id = j.id
      WHERE j.handler = 'carts.remind'
        AND jr.status = 'failed'
        AND jr.queued_at >= DATE '2025-11-01' AND jr.queued_at < DATE '2025-12-01'
    ),
    groups AS (
      SELECT t.id AS tenant_id,
        CASE WHEN a.tenant_id IS NOT NULL THEN 'Affected' ELSE 'Other' END AS group_name
      FROM tenants t
      LEFT JOIN affected a ON a.tenant_id = t.id
    ),
    tenant_counts AS (
      SELECT group_name, COUNT(*) AS tenant_count
      FROM groups
      GROUP BY group_name
    ),
    ticket_counts AS (
      SELECT g.group_name,
        SUM(CASE WHEN tk.created_at >= DATE '2025-08-01' AND tk.created_at < DATE '2025-10-01' THEN 1 ELSE 0 END) AS baseline_tickets,
        SUM(CASE WHEN tk.created_at >= DATE '2025-11-01' AND tk.created_at < DATE '2026-01-01' THEN 1 ELSE 0 END) AS incident_tickets
      FROM groups g
      LEFT JOIN tickets tk ON tk.tenant_id = g.tenant_id
      GROUP BY g.group_name
    )
    SELECT
      tc.group_name,
      tcn.tenant_count,
      ROUND(tc.baseline_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_baseline,
      ROUND(tc.incident_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_incident,
      ROUND(
        (((tc.incident_tickets::numeric / tcn.tenant_count) - (tc.baseline_tickets::numeric / tcn.tenant_count))
         / NULLIF(tc.baseline_tickets::numeric / tcn.tenant_count, 0)) * 100
      , 1) AS pct_change
    FROM ticket_counts tc
    JOIN tenant_counts tcn ON tcn.group_name = tc.group_name
    ORDER BY tc.group_name

    “Query compiles and returns the expected columns. Submitting.”

    Submitted · the SQL of the last dry run, unchanged · Submitted to tonight's batch. Your work on this request is done.

    “Submitted. The query: - Identifies the "Affected" group as tenants with at least one failed job_runs row (joined to jobs on handler='carts.remind') queued in November 2025, and labels every other tenant as "Other". - Counts tickets per group in the baseline window (2025-08-01 to 2025-09-30) and incident window (2025-11-01 to 2025-12-31), each 61 days. - Computes avg_weekly_tickets_per_tenant as tickets ÷ tenant_count ÷ (61/7), rounded to 2dp for each period, and pct_change from the unrounded per-tenant weekly rates, rounded to 1dp. - Returns exactly two rows (Affected, Other), ordered by group_name.”

  5. The report comes back overnight

    As Lucas Moreau saw it, from the small dataset the agents worked on

    group_name | tenant_count | avg_weekly_tickets_per_tenant_baseline | avg_weekly_tickets_per_tenant_incident | pct_change
    -----------+--------------+----------------------------------------+----------------------------------------+-----------
    Affected   |           10 |                                   1.89 |                                   5.19 |      173.9
    Other      |          110 |                                   0.15 |                                   0.36 |      147.5
    (2 rows)
  6. What came of it

    The memo and the queries that followed; links found by title, so inferred

    Lucas Moreau's memo to Diego Morales at the end of the week:

    • 5. Ticket-volume spike is real but mostly seasonal, not clearly caused by the incident. Affected tenants' ticket rate rose 174% from an Aug–Sep baseline (1.89→5.19/tenant/week); other tenants rose 148% over the same two periods (0.15→0.36). Source: "Support Tickets: Affected vs Other Tenants." Since both groups roughly doubled-to-tripled, most of this looks like a platform-wide holiday-season ticket bump. The extra ~26pp lift for affected tenants is suggestive but not strong evidence with only 10 tenants — I'd call this correlation, not proven cause.

    Later queries that build on this report:

    It builds on:

  7. It becomes benchmark query q133

    Changed only where the benchmark needs the same result on every system

    • spellingcast (5×)
    • numericsdocs/NUMERICS.md: rounding removed; results keep full precision; bare NUMERIC cast that only served the rounding removed; intended fraction: integer numerator cast to NUMERIC(18,6) before the division
    • made explicita selected t.col gets AS col, its standard name made explicit (4×)
    • determinismthe standard leaves the place of NULLs in a sort to the implementation: NULLS LAST ascending, NULLS FIRST descending, as in the reference results
    The benchmark text, against the submitted SQL
    WITH affected AS (  SELECT DISTINCT jr.tenant_id  SELECT DISTINCT jr.tenant_id AS tenant_id  FROM job_runs jr  JOIN jobs j ON jr.job_id = j.id  WHERE j.handler = 'carts.remind'    AND jr.status = 'failed'    AND jr.queued_at >= DATE '2025-11-01' AND jr.queued_at < DATE '2025-12-01'),groups AS (  SELECT t.id AS tenant_id,    CASE WHEN a.tenant_id IS NOT NULL THEN 'Affected' ELSE 'Other' END AS group_name  FROM tenants t  LEFT JOIN affected a ON a.tenant_id = t.id),tenant_counts AS (  SELECT group_name, COUNT(*) AS tenant_count  FROM groups  GROUP BY group_name),ticket_counts AS (  SELECT g.group_name,  SELECT g.group_name AS group_name,    SUM(CASE WHEN tk.created_at >= DATE '2025-08-01' AND tk.created_at < DATE '2025-10-01' THEN 1 ELSE 0 END) AS baseline_tickets,    SUM(CASE WHEN tk.created_at >= DATE '2025-11-01' AND tk.created_at < DATE '2026-01-01' THEN 1 ELSE 0 END) AS incident_tickets  FROM groups g  LEFT JOIN tickets tk ON tk.tenant_id = g.tenant_id  GROUP BY g.group_name)SELECT  tc.group_name,  tcn.tenant_count,  ROUND(tc.baseline_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_baseline,  ROUND(tc.incident_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_incident,  ROUND(    (((tc.incident_tickets::numeric / tcn.tenant_count) - (tc.baseline_tickets::numeric / tcn.tenant_count))     / NULLIF(tc.baseline_tickets::numeric / tcn.tenant_count, 0)) * 100  , 1) AS pct_change  tc.group_name AS group_name,  tcn.tenant_count AS tenant_count,  CAST(tc.baseline_tickets AS numeric(18,6)) / tcn.tenant_count / (61/7.0) AS avg_weekly_tickets_per_tenant_baseline,  CAST(tc.incident_tickets AS numeric(18,6)) / tcn.tenant_count / (61/7.0) AS avg_weekly_tickets_per_tenant_incident,  (((CAST(tc.incident_tickets AS numeric(18,6)) / tcn.tenant_count) - (CAST(tc.baseline_tickets AS numeric(18,6)) / tcn.tenant_count))   / NULLIF(CAST(tc.baseline_tickets AS numeric(18,6)) / tcn.tenant_count, 0)) * 100 AS pct_changeFROM ticket_counts tcJOIN tenant_counts tcn ON tcn.group_name = tc.group_nameORDER BY tc.group_nameORDER BY tc.group_name NULLS LAST
    WITH affected AS (
      SELECT DISTINCT jr.tenant_id AS tenant_id
      FROM job_runs jr
      JOIN jobs j ON jr.job_id = j.id
      WHERE j.handler = 'carts.remind'
        AND jr.status = 'failed'
        AND jr.queued_at >= DATE '2025-11-01' AND jr.queued_at < DATE '2025-12-01'
    ),
    groups AS (
      SELECT t.id AS tenant_id,
        CASE WHEN a.tenant_id IS NOT NULL THEN 'Affected' ELSE 'Other' END AS group_name
      FROM tenants t
      LEFT JOIN affected a ON a.tenant_id = t.id
    ),
    tenant_counts AS (
      SELECT group_name, COUNT(*) AS tenant_count
      FROM groups
      GROUP BY group_name
    ),
    ticket_counts AS (
      SELECT g.group_name AS group_name,
        SUM(CASE WHEN tk.created_at >= DATE '2025-08-01' AND tk.created_at < DATE '2025-10-01' THEN 1 ELSE 0 END) AS baseline_tickets,
        SUM(CASE WHEN tk.created_at >= DATE '2025-11-01' AND tk.created_at < DATE '2026-01-01' THEN 1 ELSE 0 END) AS incident_tickets
      FROM groups g
      LEFT JOIN tickets tk ON tk.tenant_id = g.tenant_id
      GROUP BY g.group_name
    )
    SELECT
      tc.group_name AS group_name,
      tcn.tenant_count AS tenant_count,
      CAST(tc.baseline_tickets AS numeric(18,6)) / tcn.tenant_count / (61/7.0) AS avg_weekly_tickets_per_tenant_baseline,
      CAST(tc.incident_tickets AS numeric(18,6)) / tcn.tenant_count / (61/7.0) AS avg_weekly_tickets_per_tenant_incident,
      (((CAST(tc.incident_tickets AS numeric(18,6)) / tcn.tenant_count) - (CAST(tc.baseline_tickets AS numeric(18,6)) / tcn.tenant_count))
       / NULLIF(CAST(tc.baseline_tickets AS numeric(18,6)) / tcn.tenant_count, 0)) * 100 AS pct_change
    FROM ticket_counts tc
    JOIN tenant_counts tcn ON tcn.group_name = tc.group_name
    ORDER BY tc.group_name NULLS LAST
    1 ms10 ms100 ms1 sHyper7.1 msDuckDB12.1 msGizmoSQL19.6 msclickhouse_brew125 msFirebolt70.8 msDataFusion85.0 msClickHouse122 ms
  8. Everything, as recorded

    The agents' own records, as the role play wrote them; only the personal data of the person who ran it is redacted

    Ines's whole session, 7 turns
    • The request, as Ines received it
      Report request from Lucas Moreau (analyst for the VP Platform Engineering):
      
      Title: Support Tickets: Affected vs Other Tenants, Baseline vs Incident Period
      Question: Was the Nov-Dec ticket rise for the 10 carts.remind-affected tenants a real spike against their own baseline, or just their normal (or seasonal) level?
      Grain: one row per tenant group (Affected vs Other), comparing two time periods
      Columns:
      - group_name
      - tenant_count
      - avg_weekly_tickets_per_tenant_baseline
      - avg_weekly_tickets_per_tenant_incident
      - pct_change
      Details: Table tickets, created_at. 'Affected' = the same 10 tenant_ids with a failed job_runs row for jobs.handler='carts.remind' queued in Nov 2025 (as established in prior reports); 'Other' = all remaining tenants. baseline period = 2025-08-01 to 2025-09-30 (61 days); incident period = 2025-11-01 to 2025-12-31 (61 days), so periods are equal length for a fair comparison. avg_weekly_tickets_per_tenant = (count of tickets for the group in that period) / tenant_count / (period_days/7.0), rounded 2dp. pct_change = (incident value - baseline value) / baseline value * 100, rounded 1dp. Two rows total: one per group. Order by group_name.
      
      Check your query with the warehouse's dry_run tool, then hand it in with submit.
    • Ines calls dry_run
      WITH affected AS (
        SELECT DISTINCT jr.tenant_id
        FROM job_runs jr
        JOIN jobs j ON jr.job_id = j.id
        WHERE j.handler = 'carts.remind'
          AND jr.status = 'failed'
          AND jr.queued_at >= DATE '2025-11-01' AND jr.queued_at < DATE '2025-12-01'
      ),
      groups AS (
        SELECT t.id AS tenant_id,
          CASE WHEN a.tenant_id IS NOT NULL THEN 'Affected' ELSE 'Other' END AS group_name
        FROM tenants t
        LEFT JOIN affected a ON a.tenant_id = t.id
      ),
      tenant_counts AS (
        SELECT group_name, COUNT(*) AS tenant_count
        FROM groups
        GROUP BY group_name
      ),
      ticket_counts AS (
        SELECT g.group_name,
          SUM(CASE WHEN tk.created_at >= DATE '2025-08-01' AND tk.created_at < DATE '2025-10-01' THEN 1 ELSE 0 END) AS baseline_tickets,
          SUM(CASE WHEN tk.created_at >= DATE '2025-11-01' AND tk.created_at < DATE '2026-01-01' THEN 1 ELSE 0 END) AS incident_tickets
        FROM groups g
        LEFT JOIN tickets tk ON tk.tenant_id = g.tenant_id
        GROUP BY g.group_name
      )
      SELECT
        tc.group_name,
        tcn.tenant_count,
        ROUND(tc.baseline_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_baseline,
        ROUND(tc.incident_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_incident,
        ROUND(
          (((tc.incident_tickets::numeric / tcn.tenant_count) - (tc.baseline_tickets::numeric / tcn.tenant_count))
           / NULLIF(tc.baseline_tickets::numeric / tcn.tenant_count, 0)) * 100
        , 1) AS pct_change
      FROM ticket_counts tc
      JOIN tenant_counts tcn ON tcn.group_name = tc.group_name
      ORDER BY tc.group_name
    • The warehouse answers
      STATUS: COMPILES (dry run on the empty schema, no data read)
      COLUMNS: group_name, tenant_count, avg_weekly_tickets_per_tenant_baseline, avg_weekly_tickets_per_tenant_incident, pct_change
    • InesQuery compiles and returns the expected columns. Submitting.
    • Ines calls submit
      WITH affected AS (
        SELECT DISTINCT jr.tenant_id
        FROM job_runs jr
        JOIN jobs j ON jr.job_id = j.id
        WHERE j.handler = 'carts.remind'
          AND jr.status = 'failed'
          AND jr.queued_at >= DATE '2025-11-01' AND jr.queued_at < DATE '2025-12-01'
      ),
      groups AS (
        SELECT t.id AS tenant_id,
          CASE WHEN a.tenant_id IS NOT NULL THEN 'Affected' ELSE 'Other' END AS group_name
        FROM tenants t
        LEFT JOIN affected a ON a.tenant_id = t.id
      ),
      tenant_counts AS (
        SELECT group_name, COUNT(*) AS tenant_count
        FROM groups
        GROUP BY group_name
      ),
      ticket_counts AS (
        SELECT g.group_name,
          SUM(CASE WHEN tk.created_at >= DATE '2025-08-01' AND tk.created_at < DATE '2025-10-01' THEN 1 ELSE 0 END) AS baseline_tickets,
          SUM(CASE WHEN tk.created_at >= DATE '2025-11-01' AND tk.created_at < DATE '2026-01-01' THEN 1 ELSE 0 END) AS incident_tickets
        FROM groups g
        LEFT JOIN tickets tk ON tk.tenant_id = g.tenant_id
        GROUP BY g.group_name
      )
      SELECT
        tc.group_name,
        tcn.tenant_count,
        ROUND(tc.baseline_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_baseline,
        ROUND(tc.incident_tickets::numeric / tcn.tenant_count / (61/7.0), 2) AS avg_weekly_tickets_per_tenant_incident,
        ROUND(
          (((tc.incident_tickets::numeric / tcn.tenant_count) - (tc.baseline_tickets::numeric / tcn.tenant_count))
           / NULLIF(tc.baseline_tickets::numeric / tcn.tenant_count, 0)) * 100
        , 1) AS pct_change
      FROM ticket_counts tc
      JOIN tenant_counts tcn ON tcn.group_name = tc.group_name
      ORDER BY tc.group_name
    • The warehouse answers
      Submitted to tonight's batch. Your work on this request is done.
    • InesSubmitted. The query: - Identifies the "Affected" group as tenants with at least one failed `job_runs` row (joined to `jobs` on `handler='carts.remind'`) queued in November 2025, and labels every other tenant as "Other". - Counts tickets per group in the baseline window (2025-08-01 to 2025-09-30) and incident window (2025-11-01 to 2025-12-31), each 61 days. - Computes `avg_weekly_tickets_per_tenant` as tickets ÷ tenant_count ÷ (61/7), rounded to 2dp for each period, and `pct_change` from the unrounded per-tenant weekly rates, rounded to 1dp. - Returns exactly two rows (Affected, Other), ordered by `group_name`.