User Churn Prediction Pipeline
Design an end to end churn prediction pipeline for a subscription SaaS platform with 50 million users. The system must ingest user activity events, billing events, support tickets, and feature usage logs, engineer beh...
Design an end-to-end churn prediction pipeline for a subscription SaaS platform with 50 million users. The system must ingest user activity events, billing events, support tickets, and feature usage logs, engineer behavioral and engagement features, train and serve ML models (XGBoost/LightGBM), and predict which users are likely to cancel their subscription within the next 30 days. The pipeline should support both daily batch scoring for the full user base and real-time scoring for high-value accounts. How would you design this end to end?
How to Approach This Problem
How to Approach This Problem Churn prediction looks straightforward on the surface, but it contains three hard problems that most candidates miss entirely. A strong answer addresses all three before touching infrastructure. Three Hard Problems Unique to Churn Prediction 1. Label definition shapes everything downstream and is rarely obvious. "Churned" sounds simple until you ask: 30 days inactive? Cancelled subscription? Stopped opening the app? A user inactive for 45 days who returns every weekend is not churned. Strong answers define the label precisely before writing any code, for example, "no session event in the past 28 days AND no scheduled future activity", and acknowledge that differe
Clarifying Questions to Ask the Interviewer
Functional Requirements What is the churn definition? Non renewal of subscription? Downgrade? 30 days of inactivity? Explicit cancellation? What is the prediction horizon? Predict churn 30 days, 60 days, or 90 days before it happens? What data sources are available? User activity logs, billing/payment events, support tickets, feature usage, NPS surveys, in app feedback? What actions will be taken on churn predictions? Proactive outreach by customer success? Automated discount offers? Product interventions? Do we need model explainability? (e.g., "this user is at risk because login frequency dropped 60% and they had 3 support tickets last month") Is there a distinction between user tiers? (fr
Envelope Estimation & Capacity Planning
Throughput Math Metric Value Calculation Total users 50,000,000 Given Paid users (churn targets) 10,000,000 ~20% conversion rate Activity events per day 500,000,000 50M users x 10 avg events/day Activity events per second (avg) ~5,800 500M / 86,400 Activity events per second (peak) ~17,400 3x peak factor (business hours) Billing events per day ~500,000 Payments, renewals, failures, downgrades Support tickets per day ~200,000 ~2% of paid users create tickets monthly Feature usage log events per day ~100,000,000 50M users x 2 avg feature interactions Avg event size ~500 bytes JSON payload Daily raw ingestion ~300 GB/day 600M total events x 500 bytes After Parquet compression ~30 GB/day ~10:1 c
Architecture Walkthrough
End to End Flow The churn prediction pipeline has four major processing stages: ingestion , feature engineering , model training , and scoring/action . Data flows through both real time and batch paths, converging at the Feature Store. 1. Event Ingestion Layer All event sources publish to Apache Kafka as the central nervous system: Source Topic Volume Schema User Activity events.user.activity 500M/day login, page view, feature click, session end Billing Events events.billing 500K/day payment success, payment failure, plan change, cancellation Support Tickets events.support 200K/day ticket created, ticket resolved, escalation, CSAT score Feature Usage events.feature.usage 100M/day feature id,
Component Deep Dive
Feature Store Architecture "The feature store is the most important component in this pipeline. Without it, you'll have training serving skew, and your model will silently degrade in production." Two tier design: Layer Technology Purpose Latency Data Format Online Store Redis Cluster Real time scoring lookups < 10ms Key value (user id → feature vector) Offline Store Parquet on S3/GCS Training data generation Seconds minutes Columnar (partitioned by date) Feature versioning: Every feature has a version (e.g., login count 7d v2 ). When computation logic changes, a new version is created. Old versions are kept for reproducibility. The model config specifies exact feature versions it was trained
Data Modeling
Core Schema Design The data model supports the full lifecycle: raw events → features → training data → model artifacts → predictions → actions. Feature Definitions Registry Why a registry? With 200+ features across multiple teams, you need a catalog. This table answers: "What features exist? Who owns them? How fresh should they be? How are they computed?" Feature Values (Offline Store) Partitioning rationale: Daily partitions by event timestamp . Training data generation queries a specific date range (e.g., 90 days of features). Partition pruning makes this fast. Old partitions are archived to cold storage after 180 days. Model Registry Churn Predictions Training Datasets Metadata User Engag