Dataford
Interview QuestionsInterview GuidesExperiencesMock InterviewsPricing
Get started

Design ML Network Repair Pipeline

HardSystem Design00:00
Practice interviewer
In session
5 left
00:00

Your question is Design ML Network Repair Pipeline. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Product Context

Meta operates a large global network spanning datacenters, backbone links, and edge POPs that support Facebook, Instagram, WhatsApp, and internal infrastructure. Design an ML system that detects network anomalies, triages likely root causes, and recommends or triggers directed repair actions for SiteOps and network automation systems.

Scale

SignalValue
Network devices monitored2.5M routers, switches, optics, and hosts
Telemetry events/day45B counters, logs, alerts, and flow summaries
Peak telemetry ingest1.2M events/sec
Concurrent incidents/day25K anomaly clusters
Candidate repair actions5K runbooks / automation actions
Online latency budget3s p99 from anomaly trigger to ranked repair plan

Task

  1. Clarify the functional goals across detection, incident clustering, root-cause triage, and repair recommendation.
  2. Design an end-to-end multi-stage ML architecture, including retrieval, ranking, and re-ranking of candidate causes and repair actions.
  3. Specify the offline and online data pipelines, feature store design, and training cadence for fast-changing network conditions.
  4. Choose models for each stage and explain tradeoffs in accuracy, latency, interpretability, and operator trust.
  5. Define evaluation strategy, including offline metrics, online rollout, human-in-the-loop validation, and guardrails.
  6. Identify failure modes such as feature drift, training-serving skew, bad automated actions, and telemetry outages, with detection and mitigation plans.

Constraints

  • False positives are expensive: unnecessary repairs can impact production traffic.
  • Some actions may be auto-executed only for low-risk classes; others require human approval in internal Meta tooling.
  • Telemetry can be delayed, missing, or inconsistent across regions.
  • The system must remain useful during partial outages when some feature sources are unavailable.
  • Explanations must be available for triage recommendations to support QA, SiteOps, and incident review.