Casebook/Case 11
Serving & cost

A platform for real-time predictions

Building shared online inference around contracts, reliability, and product-team needs.

Reported by the primary sourceFACT LAYER

What we can attribute directly

Shopify describes platform work supporting real-time machine-learning predictions.

The account covers model serving and the surrounding platform responsibilities.

Read Shopify Engineering — Real-time predictions Primary source · last checked 26 Aug 2026
01 · Problem & constraints

The operating envelope

Merchant-facing latency, high availability, model diversity, safe releases, and platform operability.

Actors

Model teams, platform owners, operators, downstream product systems, and people affected by decisions.

Evidence

Versioned data, configs, traces, artifacts, deployments, and outcomes aligned on one timeline.

Failure cost

Teams can train models but lack a consistent way to expose predictions with production guarantees.

02 · Architecture reconstruction

Trace the system before naming the bug.

  1. 01

    Producers emit versioned data or model artifacts.

  2. 02

    A platform validates, computes, stores, schedules, or routes them.

  3. 03

    Training or inference consumes the exact declared version.

  4. 04

    Telemetry joins the decision to system, data, and model identity.

  5. 05

    Operators compare outcomes, stop conditions, and the last known-good path.

03 · Symptoms & investigation

Follow the evidence boundary by boundary.

Symptoms

Teams can train models but lack a consistent way to expose predictions with production guarantees.

Investigation

Trace request validation, features, model lookup, runtime, logging, timeout, and fallback for a single decision.

DIAGNOSTIC EXERCISE

A feature service exceeds its timeout. Specify the response, log record, and alert that preserve safety.

Open investigation scaffold
  1. Write the earliest known-bad timestamp.
  2. Compare exact identities on either side of that boundary.
  3. Find the smallest affected slice and a known-good counterexample.
  4. Separate mitigation from root-cause confirmation.
04 · Root cause & fix

Repair the contract, not only the symptom.

ROOT CAUSE

Serving treated as model loading omits dependency, ownership, and degradation contracts.

FIX

Offer a typed serving path with versioned artifacts, readiness, observability, and controlled release.

Rollout

Start in shadow, canary by store or traffic slice, and require product fallback.

05 · Rejected alternatives

Reason about the tempting shortcuts.

  • A single opaque endpoint for every latency class.
  • Relying on infrastructure health without prediction telemetry.
06 · Monitoring after the fix

Make recurrence visible early.

01

End-to-end and stage latency

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

02

Model and feature version exposure

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

03

Fallback and decision outcome

Define owner, slice, normal range, alert persistence, and the exact mitigation the alert should trigger.

REUSABLE PRODUCTION PATTERN

Online inference is a user-facing distributed system with a model inside.

Carry this pattern into assignments as a design constraint and into incident reviews as a hypothesis—not as proof about an unpublished system.