What is an MLOps platform?

An MLOps platform is the shared system a company uses to train, store, release and monitor many machine learning models. It usually has five parts: versioned data and a feature store, training pipelines, a model registry with fixed versions and movable aliases, a rollout path with shadow and canary stages, and monitoring that can trigger a retrain.

What is a model registry, and why use aliases instead of version numbers?

A model registry is a catalogue of trained models, where each training result is stored as a version that never changes, together with its lineage. An alias, such as champion, is a movable name that points at one version. Serving loads the alias, so promotion and rollback each move one pointer, with no rebuild. MLflow deprecated the older stages in version 2.9.0 in favour of aliases.

What is train/serve skew and how does a feature store prevent it?

Train/serve skew means the model gets different feature values in production from the ones it was trained on, so it quietly gets worse with no error. A feature store prevents the common cause by keeping one definition per feature and serving it from an offline store for training and an online store for live requests. Its point-in-time join also stops training rows from reading values from their future.

What is the difference between shadow deployment and canary deployment for ML models?

In a shadow deployment the new model scores every live request but its answers are not used, so both models are compared on the same rows with no risk to users. In a canary deployment the new model really answers a small random share of requests, which is the only way to see how users react. The usual order is shadow, then a small canary, then everyone.

How do you detect model drift in production?

Watch three signals from the prediction log: input drift per column (for example with PSI or a KS test), drift in the model's own outputs, and real accuracy on labelled rows when labels arrive. Input and output checks are fast but only show that data moved; only the labelled check shows the model got worse.

How do you make an ML model reproducible?

Record the four things that decide what training produces: a named data version with its hash, the code commit, the environment as a container image built from a hash-locked dependency file, and every setting including the random seed. Also store a hash of the model's answers on fixed rows: a rebuild with the same answers hash is the same model. GPU training is often not exactly repeatable, so for GPU models compare answers within a stored tolerance, or keep and reload the original file.

What is asked in an MLOps system design interview?

Usually: design a platform that takes models from training to production for many teams. Expect to cover data versioning, training pipelines and their triggers, a model registry with versions and aliases, a promotion gate, shadow and canary rollout, rollback, drift and accuracy monitoring, train/serve skew and the feature store, and multi-tenant GPU quotas.

How do you roll back a bad ML model quickly?

Serve models through an alias in a model registry, never a version number. Rolling back is then one write: point the champion alias back at the last good version, which takes seconds and needs no retraining or rebuild. Log the move and keep the bad version for the review.

How should a model retraining pipeline be triggered?

Use a schedule as the floor, and add triggers for new labelled data and for monitoring alarms. Compare an alarm against a fixed level or the current champion, not against the model's own first week, which can be anchored low. Every retrain, however it was triggered, must pass the same promotion gate before it replaces the live model.

System design interview guide

MLOps System Design Interview: Design an ML Platform for Training, a Model Registry, Safe Rollout and Monitoring

Short answer

A machine learning model is a program that learns a rule from examples, and an MLOps platform is the shared system many teams use to train, store, release and watch their models. Every training run reads a fixed copy of the data and runs in a container with fixed library versions, so the model can be rebuilt later. Each trained model is saved as a version that never changes in a model registry, a catalogue of trained models. Live serving loads an alias, a movable name such as champion that points at one version, so a rollback just points the alias back at the last good version. A new version must beat the current one on test rows kept aside from training, then run in shadow (it answers, but nobody uses its answers) and then as a canary (it serves a small share of users). Monitoring watches for drift, meaning the live inputs no longer look like the training inputs, and checks real accuracy once the true answers arrive, because drift alone does not prove the model got worse.

in this guide

Design an MLOps Platform, part by part

8 parts open to everyone · 3 with a free account · 3 with the course

Requirementsopen
Scale estimatesopen

Why this question is asked

The question tests whether a candidate has looked after models for months after their first release. A weak answer draws 'train', an arrow and 'serve'. To serve a model means to answer live requests with it. That answer breaks on the next question: which data trained the model that is live right now, and how do you go back to last week's model in one minute? A strong answer treats the model as the smallest part of the system. It names the four things that must be versioned together (data, code, environment and settings), because a model file alone cannot be rebuilt. It knows that a model can fail silently: latency (the time to answer one request) stays low, no error appears, and accuracy falls. It treats rollout as a statistics problem, because two equally good models score differently on any test by chance. It treats the platform as a product for other engineers. Each team is a tenant with its own quota. And the path is self-serve, which means teams do the work themselves without waiting on the platform team.

This page is the free part.

The course goes deeper on the MLOps Platform design

₹499 in India$49 everywhere elseonce, for the whole course

The System Design course covers the MLOps Platform design across a run of lessons, not one page. These 4 alone are about 116 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.

Live from the course bench

Before you design MLOps, try the questions it rests on.

Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.

Two engineers sketching a system design on a whiteboard

where the work happens

Stuck on a card?

Ask the course tutor. It answers with a real diagram, drawn for your question.

Ask the tutor

Laying out the cards…

Requirements

Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.

Functional requirements

Register datasets as fixed, named versions, and record which version every training run used
Let a team define a training pipeline as configuration (data source, feature list, training code, compute size) and run it on a schedule, on new data, or on an alarm

Go deeper

This guide is built on these 6 lessons. Each one teaches one piece of the MLOps Platform design above, step by step.

Practice with 770 system design lessons

Lifetime access for ₹499 in India or $49 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.

Get lifetime access See all interview problems

It ends with a short quiz, so you know it stuck.

Want the short-answer question list instead? See the MLOps interview questions guide

Two courses by the author of this page:

System Design

770 lessons · 18 free to read

₹499 in India · $49 elsewhere, once

Get System Design

You own this course

AI Engineering

210 lessons · 10 free to read

₹999 in India · $49 elsewhere, once

Get AI Engineering

You own this course

Every lesson in both courses has an AI tutor beside it. It reads the same lesson you are reading and answers your questions from it. Try the tutor

Save your progress and get the AI Engineering cheat sheet PDF

AI Engineering Cheat Sheet: what our labs measured, one rule per result. 12 pages. Free with an account.

A machine learning model is a program that learns a rule from examples instead of being told the rule. For example, it looks at a million past card payments and learns which ones were fraud. This learning step is called training. Training one model can take a few days of work. Running three hundred of them for thirty teams is a much bigger job. Each model needs fresh data, a training run that someone can repeat next month, a safe way to reach real users, and a way to undo a bad release in seconds. Each model can also get worse with no error message at all, because the world it learned from keeps changing. MLOps means running machine learning models in real products with the same care as any other software. An MLOps platform is one shared set of tools for all the teams. With it, a team puts its model live by filling in a form. It does not have to build its own pipeline (the chain of steps that trains a model), its own registry (the catalogue of trained models), or its own dashboards (the screens of charts that show if a model is healthy). Google's well-known paper on this problem says the model's own code is only a small part of a real machine learning (ML) system. This page designs the rest.

MLOps means running machine learning models in real products with the same care as any other software. An MLOps platform is the shared system a company uses to train, store, release and watch many models. Design it as one loop with five parts. First, data: every training set is a fixed, named copy, so a model can be rebuilt later. Second, a training pipeline: a chain of steps (check the data, build the inputs, train, test) that runs on a schedule or when an alarm fires. Each step runs inside a container image, a sealed package that holds the code, Python and every library. The library versions are pinned, which means fixed. Third, a model registry: a catalogue where every trained model becomes a version that never changes. It also holds aliases, which are movable names such as champion that point at one version. Serving means answering live requests with a model, and serving loads the alias, so a rollback just points the alias back. Fourth, rollout. A new version must beat the current one on held-out rows: examples kept aside and never used in training, so they give a fair test. The rule for winning is written down in advance. Then the new version runs in shadow: it answers live requests, but nobody uses its answers. Then it runs as a canary: it really answers a small share of requests. Fifth, monitoring. Input drift means the live inputs no longer look like the training inputs. Drift alarms are cheap and fast, but they do not prove harm. So the platform also checks real accuracy on a small labelled sample: rows where the true answer is now known. A feature is one input value for a model, such as a customer's purchases in the last 30 days. A feature store gives training and serving one definition of each feature. Its point-in-time join gives each training row only the values that existed at that row's own time, so training never sees the future. Around it all sit multi-tenancy (many teams sharing one platform safely) and quotas (a cap on how much each team may use, especially of GPUs, the costly chips that speed up training).

Roni Das

17 October 2026 · 43 min read

Where it shows up

This question is asked for ML platform engineer, MLOps engineer and ML infrastructure roles, and for senior or staff backend roles on teams that build tools for data scientists. It comes in several forms: design an MLOps platform, design an ML platform, design a model registry, design a system to retrain and deploy models, or how would you take a model from a notebook to production. Companies that run many models and have written about their own platforms, such as Uber with Michelangelo, show the shape of the answer. We do not list which companies ask it, because we could not find a public source we trust that says so.

Spec sheetan MLOps Platform

01Teams and models (interview assumption): 30 teams, 300 models in production, 100 of them answering live requests
02Training runs: about 3,300 runs a week, about 470 a day (arithmetic)
03GPU time: about 3,300 GPU-hours a week, so about 20 GPUs busy on average and about 60 at the nightly peak (arithmetic)
04Model files in the registry: about 3 TB a year (arithmetic)

worked through below, with the maths

Data modelfree account

Deep dives (7)free account

Open Table Formats: What Delta Lake, Iceberg and Hudi Actually Write Down
Delta Lake, Apache Iceberg and Apache Hudi: what is actually in the metadata? I wrote the same 11,198,026 NYC taxi trips into all three, three commits each, and opened every metadata file. Delta kept 3 JSON commits, Iceberg 10 files in a four-level tree, Hudi a timeline and a metadata table. All three returned January's exact 3,475,226 rows when asked for the first version. After 120 small appends, an Iceberg planner opened 122 metadata files and a Delta reader 22; Hudi packed the rows into 1 file group instead of 120 files. Compaction fixed the count, and cleanup ended time travel.
72 min · diagrams · code you run · quiz
Canary Deployment
Routing a small percentage of production traffic to the new version and monitoring before full rollout.
12 min · diagrams · quiz
Container Registry
Centralized storage for container images, the Docker Hub, ECR, and GHCR of the world.
14 min · diagrams · quiz
Shadow Testing
Sending production traffic to a new version without affecting users, testing real-world behavior safely.
18 min · diagrams · quiz

all part of

System Design Masterclass

770 lessons · about 283 hours · 18 free to read

₹499in India, by UPI

$49everywhere else, by PayPal

Get the System Design course Read 18 lessons free first

You own this course

Continue with Open Table Formats: What Delta Lake, Iceberg and Hudi Actually Write Down

pay once,
yours for life

Track every run: settings, the random seed (the starting number that fixes all random choices in training), scores, the code commit (the exact saved version of the code), the data version, the container image and the files it produced

Keep a model registry where each trained model becomes a version that never changes, with movable aliases such as champion (the live version) and challenger (the new version being tested)

Gate promotion: a new version only replaces the current one if it wins on the same held-out rows by a rule set in advance

Roll out in steps (shadow, then canary, then everyone), and roll back (return to the last good version) by moving an alias, in seconds, with no rebuild

Serve features (the input values a model reads) from one definition for both training (history) and live requests (latest value)

Monitor inputs, outputs and real accuracy per model, and open a retrain proposal when a check fails

Give each team its own space with GPU and CPU quotas, and show each team its own cost

Control who may move the champion alias: an automatic gate for low-risk models, a named person's approval for high-risk ones, both logged in alias_events

Non-functional requirements

Reproducible: any registered version can be rebuilt from its record, or at least loaded and checked against stored answers
Auditable: every promotion and rollback is logged with who, when, which versions and why
Safe by default: a bad version reaches only a small share of traffic before a check can stop it
Fast rollback: under a minute, because it is a pointer move, not a training run or a new build
Isolated: one team's runaway training job cannot take every GPU in the cluster
Cheap to watch: monitoring runs off the request path and adds no latency to predictions
Private: prediction logs hold user inputs, so they have access controls, a retention limit and a way to delete one person's rows
Self-serve: a new model reaches production through templates, not through tickets to the platform team

Back-of-envelope scale estimates

Show your math. Pulling numbers from thin air signals you have not thought about the load.

Teams and models (interview assumption)

30 teams, 300 models in production, 100 of them answering live requests

Say these out loud first. Everything below is arithmetic on them.

Training runs

about 3,300 runs a week, about 470 a day (arithmetic)

Assume each production model retrains once a week: 300 runs. Assume each team also runs 10 experiments for every production retrain: 3,000 more. 300 + 3,000 = 3,300 runs a week. 3,300 / 7 = 471 a day. Most start at night, so the scheduler must handle a burst.

GPU time

about 3,300 GPU-hours a week, so about 20 GPUs busy on average and about 60 at the nightly peak (arithmetic)

Assume half the runs need one GPU for 2 hours: 1,650 x 2 = 3,300 GPU-hours. A week has 168 hours, so 3,300 / 168 = 19.6 GPUs busy all the time on average. If runs bunch into a few night hours, the peak is about 3 times the average, about 60 GPUs.

Model files in the registry

about 3 TB a year (arithmetic)

300 models x 52 weekly versions = 15,600 registered versions a year. At an assumed 200 MB per model file, 15,600 x 200 MB = 3.12 TB. Run metadata is a few kilobytes per run, so the registry is a small database plus a large object store.

Prediction logs

about 1.7 TB a day if every prediction is logged (arithmetic)

Assume the 100 online models answer 20,000 requests a second in total, and each log row (inputs, output, model version, request id) is 1 KB. 20,000 x 1 KB = 20 MB a second. 20 MB x 86,400 seconds = 1.73 TB a day. It goes to a queue and cheap object storage, never to the serving database.

Drift checks

about 290,000 small checks a day (arithmetic)

300 models x 40 input columns = 12,000 columns to watch. Checked every hour: 12,000 x 24 = 288,000 checks a day. Each compares two histograms of about 10 bins, so the compute is tiny. The hard part is deciding which alarm means harm.

Rows a canary sees

measured: a 5% canary saw 110 labelled rows in 2,000 half-hours

Measured in our canary and shadow lesson on Elec2, a public electricity price dataset where one labelled row arrives every half-hour. A 20% canary saw 419 rows and a 50% canary saw 1,007. The rule: rows seen = labelled traffic x canary share x time. Work it out before you pick the share.

High-level architecture

Draw the platform as a loop of five parts on top of one shared compute cluster. The figure groups them into four bands: data, train, register, and serve-and-watch. Data. Object storage is a cheap store for large files, and Amazon S3 is the best-known one. Every training set is a named, fixed version there. It can be a tag on a snapshot (a frozen copy of a table at one moment). Or it can be a set of files named by their hash, a short fingerprint computed from the bytes, which changes if even one byte changes. Next to it sits a feature store. The feature store keeps each feature's definition once and serves it two ways: an offline store with full history for training, and an online store with the latest value for live requests. Training. A pipeline orchestrator is a scheduler program that runs steps in the right order. Airflow and Kubeflow Pipelines are two common ones. Each model's pipeline is a DAG, a directed acyclic graph: steps joined by arrows, with no loops. The steps: check the data, build the training set, train, evaluate against the current model, and register if it wins. Each step runs in a container image built from a lock file, a file that lists the exact version of every library. Kubernetes, the system that runs containers across many machines, runs each step in the team's own namespace: a walled-off space with its own quota. Registry. The model registry, such as MLflow's, stores each trained model as a version that never changes, with its lineage: which data version, code commit, image and seed produced it. Aliases such as champion point at one version. CI (continuous integration: the system that builds and tests code automatically, such as GitHub Actions) builds one serving image per model type, and that image loads whichever version the alias points at. A rollback then needs no new image. Serving and rollout. A deployment controller reads the alias and runs the model on Kubernetes. Online means the model answers each request as it arrives. A batch job scores a large set of rows at once, for example every night. New versions go through shadow and then canary, and promotion and rollback both move the alias. Monitoring. Every prediction is logged to a queue and then to object storage, off the request path. Scheduled jobs compute input drift, output drift, and real accuracy when labels arrive, and push the numbers to Prometheus, a database for numbers over time. Grafana draws dashboards from those numbers. A failed check opens a retrain proposal that goes back to the pipeline, through the same gate. That arrow back is what makes it a loop.

In a real interview, sketch this on the whiteboard before diving into any single box.

One fraud model, from a nightly training run to live traffic, and back

Follow version 7 of a fraud model through the platform. This is a good order to explain the design in an interview.

1
Triggered
The weekly schedule fires, or a monitoring check failed. The orchestrator starts the fraud team's pipeline in the team's namespace, with the team's GPU quota.
2
Data pinned
The first step resolves the training data to a fixed version, for example the tag train-week-51, and records its hash.
3
Data checked
A validation step checks row counts, column types and value rules. Broken data stops the run before any GPU time is spent.
4
Training set built
The pipeline asks the feature store's offline store for each labelled row's features as they were at that row's time: a point-in-time join. No row sees a value whose event time is after its own time. To also block values that were written later but stamped with an old time (backfills), the join must filter on the time each value was written, which Feast does only when asked.
5
Trained
Training runs in a container built from a hash-locked dependency file, with a fixed seed. The tracking server records settings, metrics, the data hash, the code commit and the image digest (the image's own hash).
6
Gated
The new model and the current champion are scored on the same frozen held-out rows. A rule written down before the run decides: promote only if the new model wins by a set margin, or by a paired test, which compares the two models row by row on the same rows.
7
Registered
Version 7 is added to the registry with its lineage, its input signature (the expected column names and types), and its answers on a stored set of rows. The alias challenger moves to version 7.
8
Shadowed
Serving sends every live request to both models. Only the champion's answer is used. The platform counts the rows where they disagree.
9
In canary
A small random share of requests is answered by version 7. The platform compares live metrics at checkpoints fixed in advance, and stops the rollout on a clear loss.
10
Promoted
The alias champion moves from version 6 to version 7. The move is logged. Version 6 stays in the registry, unchanged.
11
Watched
Prediction logs flow to monitoring. Drift checks run hourly, and accuracy is checked as labels arrive. If version 7 turns out worse, rollback moves champion back to version 6 in seconds.

Core components

Walk through each service. The interviewer wants to hear what each one owns, not just the names.

Dataset versioning

Turns 'the sales table' into 'the sales table as it was at tag train-week-51'. DVC keeps a small pointer file in Git and the bytes in object storage. Iceberg keeps table snapshots you can tag. Delta Lake keeps numbered table versions you can read back, so record the version number. In both, set file cleanup so it never deletes files that a recorded version still needs.

Feature store

Holds each feature's definition once, as code with an owner. The offline store keeps every past value with the time it became valid, for training. The online store keeps only the latest value per entity (the thing a feature describes, such as one customer), for fast lookups at serving time. A scheduled job copies the latest values from offline to online. Feast is the common open-source example.

Pipeline orchestrator

Runs each team's pipeline as a DAG of steps, on a schedule or on an event, with retries per step. Airflow runs steps as tasks through a scheduler and workers. Kubeflow Pipelines runs each step as a container on Kubernetes. The orchestrator decides what runs and when; Kubernetes decides where.

Experiment tracking and lineage store

Records every run: settings, seed, metrics, files produced, the data version and hash, the code commit, and the container image digest. Google's MLOps guide calls this the metadata store.

Model registry

A catalogue of registered models. Each model has numbered versions that never change, and aliases that can move. It is a small database plus pointers to model files in object storage.

Promotion gate and rollout controller

Decides whether a new version may move forward. It scores the new and current versions on the same rows by a rule fixed in advance, runs shadow and canary stages, and moves the alias. It refuses a version with no lineage record or no input signature.

Serving layer

Runs models as online services on Kubernetes or as batch jobs. It loads the version an alias points at, checks incoming requests against the version's signature, and logs every prediction with its model version.

Monitoring and retrain trigger

Reads the prediction log off the request path. It computes input drift per column, output drift, and real accuracy on labelled rows, and pushes them to Prometheus for Grafana dashboards. A failed check opens a retrain proposal, which goes back through the gate.

Tenancy, quotas and cost

Gives each team a Kubernetes namespace with a ResourceQuota, which caps the CPUs, memory and GPUs that team can request. Training jobs wait in a queue with priorities. The platform tags every run and every serving pod with its team, so each team sees its own GPU bill.

the deep dive

Data model

dataset_versions. One row per named version. row_hash is a hash over every row that ignores their order, so it catches a changed value but not a harmless reordering. Build it by adding…

free with an account

Every table for an MLOps Platform, its keys, and which store fits it and why.

One tap with Google. Free, no card.

the deep dive

Deep dives

Reproducibility: a model version is a receipt for data, code and environment. Reproducible means you can build the same model again, or at least prove that a file is the same model. A model file alone cannot do this. Four things decide what a…

free with an account

7 deep dives on the parts that break at scale, with 3 diagrams: Reproducibility: a model version is a receipt for data, code and environment; The model registry: fixed versions and movable aliases; Train/serve skew and the point-in-time join.

One tap with Google. Free, no card.

the deep dive

Trade-offs to discuss

Build the platform, or buy a managed one. A managed service (a cloud ML platform) gets a few teams to production fast, with no cluster to run. Building on open tools (Airflow or Kubeflow, MLflow, Feast…

free with an account

6 decisions an interviewer expects you to defend, each with the alternative and why it loses here.

One tap with Google. Free, no card.

for course owners

What the interviewer asks next

A model went live yesterday and the fraud loss doubled overnight. What do you do first?

with the System Design course

5 follow-up questions with model answers, the interview scorecard for this question, and a mock interview on Design an MLOps Platform with the AI tutor.

Unlock with the course · $49One payment, lifetime access to every lesson.

How an MLOps Platform actually does it

Three public sources describe the shape of this design well. Google's 2015 NeurIPS paper, Hidden Technical Debt in Machine Learning Systems, argues that ML systems carry hidden costs that grow over time, much like a debt. Two of the risks it names are easy to picture: a model depends on data that other teams can change without warning, and the outside world changes after the model was trained. Most of this platform exists to keep those costs down. Google Cloud's guide, MLOps: Continuous delivery and automation pipelines in machine learning, describes three levels: level 0 is manual, level 1 automates the training pipeline with data and model checks, triggers and a metadata store, and level 2 also builds, tests and releases the pipeline's own code automatically, which is called CI/CD (continuous integration and continuous delivery). It says only a small fraction of a real ML system is the ML code. Uber's 2017 post, Meet Michelangelo, describes a platform Uber began building in mid 2015. It covers the whole workflow: manage data, train, evaluate, deploy, predict and monitor. Its shared feature store held about 10,000 features, and its busiest models served more than 250,000 predictions a second. A model was found by an id plus an optional tag or alias, much like the aliases on this page. Predictions were logged and later joined to real outcomes to measure live accuracy. The open-source tools named on this page (MLflow, Feast, Airflow, Kubeflow Pipelines, DVC and Kubernetes) each cover one of these parts, and their documentation is listed below. The measured numbers on this page come from labs in our AI Engineering course. They were run on one laptop with scikit-learn and public datasets. Each lesson states its own limits, and each number here says which lesson it came from.

Sources

the question most readers have next

What would you have to get right to run the MLOps Platform design for real users?

The design on this page is the shape. Running it means handling the failures, the load and the data that the shape does not show. The lessons below teach those parts, starting with "Open Table Formats: What Delta Lake, Iceberg and Hudi Actually Write Down".

Where this is used in industry

The real examples, each with its source, are on this page: How an MLOps Platform actually does it.

The lessons that teach the next part

Delta Lake, Apache Iceberg and Apache Hudi: what is actually in the metadata? I wrote the same 11,198,026 NYC taxi trips into all three, three commits each, and opened every metadata file. Delta kept 3 JSON commits, Iceberg 10 files in a four-level tree, Hudi a timeline and a metadata table. All three returned January's exact 3,475,226 rows when asked for the first version. After 120 small appends, an Iceberg planner opened 122 metadata files and a Delta reader 22; Hudi packed the rows into 1 file group instead of 120 files. Compaction fixed the count, and cleanup ended time travel.
Open Table Formats: What Delta Lake, Iceberg and Hudi Actually Write DownSystem Design course72 min
Routing a small percentage of production traffic to the new version and monitoring before full rollout.
Canary DeploymentSystem Design course12 min
Centralized storage for container images, the Docker Hub, ECR, and GHCR of the world.
Container RegistrySystem Design course14 min
Sending production traffic to a new version without affecting users, testing real-world behavior safely.
Shadow TestingSystem Design course18 min

Stuck on a step? Every lesson has an AI tutor beside it. Ask it your question and it answers from the lesson you are reading. Try the tutor

Get the free System Design Interview cheat sheet (PDF)

Where this is taught

System Design Masterclass

770 lessons · about 283 hours · 18 free to read

₹499 in India by UPI$49 elsewhere by PayPal, once, for life

See the System Design course

You own this course

Frequently asked questions

Canary and Shadow: How Much Live Traffic It Takes to See a Worse ModelAI Engineering · ml lifecycle · 74 min

India: UPI, cards or netbanking through Razorpay. Elsewhere: PayPal. Download at once from My packs.

Free PDF · 79 pages

25 real tech interview questions, answered in full

Five from each of our AI, GenAI, Inference, Maths for ML and Forward Deployed packs. Each with a diagram and a model answer. Free by email.

Also by the same author

210 lessons · about 219 hours · 10 free to read

₹999 in India by UPI$49 elsewhere by PayPal, once, for life

See the AI Engineering course

what a reader said

The concepts were explained in a clear and structured way, with practical examples that made even complex system design topics easier to understand. I especially liked the focus on real-world architecture, scalability, trade-offs. The content was well designed, engaging, and highly useful for anyone looking to strengthen their system design skills. Highly recommended for software engineers preparing for system design interviews or wanting to build a stronger foundation in designing scalable systems.

Verified reader · System Design Masterclass · read 69 lessons · all reviews

MLOps System Design Interview: Design an ML Platform for Training, a Model Registry, Safe Rollout and Monitoring

Design an MLOps Platform, part by part

Why this question is asked

The course goes deeper on the MLOps Platform design

Before you design MLOps, try the questions it rests on.

Requirements

Functional requirements

Go deeper

Practice with 770 system design lessons

Get all 150 questions in the ML Engineering and MLOps pack

Non-functional requirements

Back-of-envelope scale estimates

High-level architecture

One fraud model, from a nightly training run to live traffic, and back

Triggered

Data pinned

Data checked

Training set built

Trained

Gated

Registered

Shadowed

In canary

Promoted

Watched

Core components

Dataset versioning

Feature store

Pipeline orchestrator

Experiment tracking and lineage store

Model registry

Promotion gate and rollout controller

Serving layer

Monitoring and retrain trigger

Tenancy, quotas and cost

Data model

Deep dives

Trade-offs to discuss

What the interviewer asks next

How an MLOps Platform actually does it

Lessons to study before this interview

Related system design interview questions

What would you have to get right to run the MLOps Platform design for real users?

Where this is used in industry

The lessons that teach the next part

Frequently asked questions

What is an MLOps platform?

What is a model registry, and why use aliases instead of version numbers?

What is train/serve skew and how does a feature store prevent it?

What is the difference between shadow deployment and canary deployment for ML models?

How do you detect model drift in production?

How do you make an ML model reproducible?

What is asked in an MLOps system design interview?

How do you roll back a bad ML model quickly?

How should a model retraining pipeline be triggered?

Are you ready for Design an MLOps Platform?