CrackOps
Interview PrepTracksLinuxAWS LabSoonInterview RoomSoon
Sign inStart free
CrackOps

Interview prep for the people who keep production up.

[email protected]
ProductInterview PrepTracksDashboardInterview Room
RolesDevOpsSREPlatformCloud
CompanyAboutContactPrivacyTerms
© CrackOps
Tracks/CI/CD & Release Engineering
Expert 4 minSystem design

Design a deployment system that rolls out thousands of services safely with automatic canary analysis

Scenario

A professional social network runs about 3,000 services owned by 400 teams, across six data centres in two regions. Teams ship around 1,500 production deploys a day. Today each team uses its own scripts and eyeballs dashboards during rollouts. Two recent outages were bad deploys that went global within 20 minutes, one of them during a holiday change freeze.

The interviewer asks

“Design the deployment system for the whole estate: how a change moves from one instance to every data centre, how the system decides on its own that a canary is bad, and how it rolls back. Tell me how this system behaves during an incident or a change freeze.”

The 30-second answer

I'd build a central deploy orchestrator, a durable workflow per deployment, that every service uses through a declarative manifest, with thin agents in each data centre doing the actual rollout. Every change moves in waves: a canary next to a fresh baseline of the old version in one DC, then that whole DC, then the rest of the region, then the other region, with bake times between waves. An automated judge compares canary and baseline per metric with a Mann-Whitney test and tolerated effect sizes, scores the result, and rolls back automatically on failure. Bake time is derived from traffic so each test has enough samples. A policy engine checks freezes, active incidents and error-budget state before every step, and there's a global halt switch and dependency-aware concurrency limits. The deploy system itself is built not to depend on anything it deploys.

Sign in to finish this question

A free account unlocks the rest of it, and saves your progress across every track.

  • The voiced mock interview (4 min)
  • The full senior answer, step by step
  • Animated architecture diagrams
  • The whole conversation, 12 turns
  • Deep dive: how it works, mistakes, risks and trade-offs
  • 3 copy-ready command snippets
  • 5 follow-up questions they'll ask next
  • A self-check of 8 things interviewers listen for
Create a free accountSign in

More CI/CD & Release Engineering interview questions

  • Walk me through a production deployment and rollback strategy.
  • How do you enforce approvals and segregation of duties in CI/CD without slowing delivery to a crawl?
  • Production can only change Saturday 02:00 to 05:00. How do you run releases so the window stops failing?
  • Design a deployment pipeline where changes that touch money get extra safety without slowing every team down
  • A deploy passed canary cleanly, then payment success slowly decays over an hour. How do you debug it?
  • A release passed automated canary analysis, but a member-facing metric dropped a day later. What did the canary miss?
All CI/CD & Release Engineering questions

Linux commands for this track

  • bash: variables Shell variables: assign, quote, default and export
  • bash: if Conditions: if, elif, else, test brackets and case
  • bash: loops Loops: for, while read, until and retry
  • bash: functions Functions: name a block, pass arguments, return a status
  • bash: arrays Arrays: lists and key-value maps in bash
  • bash: exit codes Exit codes, $?, set -euo pipefail and trap
  • bash: redirection Redirection: stdout, stderr, 2>&1, /dev/null and here-docs
  • bash: arguments Script arguments: $1, $#, "$@", shift and getopts