Design an AI-Based Real-time Fraud Detection System — System Design Interview Practice

Interview prompt

Design a real-time fraud decisioning platform that combines rules, ML, graph and behavioral signals, adapts to new patterns, and returns explainable allow/review/deny decisions without blocking legitimate transactions.

• Define the transaction decision contract, feature freshness, entity graph, rules/model versions, action thresholds, reason codes, and review lifecycle.
• Keep the synchronous path bounded with precomputed behavior features; handle duplicate requests, unknown outcomes, delayed labels, and provider timeouts.
• Separate scoring from case management, training, feedback, regulatory reporting, and model rollout; make decisions reproducible and auditable.
• Explain latency/recall tradeoffs, bias, privacy, adversarial adaptation, failover, observability, and safe pending/manual-review behavior.

Requirements and scale assumptions

• Score payment or account events, combine rules and model signals, return allow/review/deny with reason codes, and persist the decision evidence.
• Maintain entity relationships and velocity features, open investigator cases, accept labels/chargebacks, and generate compliance reports.
• Support idempotent retries, model/rule rollback, privacy controls, feedback loops, delayed labels, and provider or feature-store failure.
• Meet p95 scoring latency under 50ms with a documented failover decision and preserve evidence for every outcome.
• Scale to 100k transactions per second and high-cardinality entity graphs without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 100k transactions/second peak and 1B entity relationships
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 100k transactions/s; 1B relationships — Capacity assumption that drives partitioning and backpressure.
• Latency target: scoring p95 < 50ms; evidence complete — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The transaction ledger and signed decision evidence are authoritative; features and cases are derived views.
• Async boundary: At-least-once workers — Keep Use ensemble models (gradient boosting + neural networks), Implement feature stores for real-time feature computation, Use graph neural networks for relationship analysis off the synchronous path.

Key entities

• DatasetVersiondatasetId, version, schemaHash, qualityStatus, lineage, createdAt

  Immutable ai based real time fraud detection system input version used for reproducible training, evaluation, or replay.

• FeatureSnapshotentityId, featureSetVersion, eventTime, values, sourceWatermarks

  Point-in-time ai based real time fraud detection system features with source watermarks so online and offline values can be compared.

• TrainingRunrunId, datasetVersion, codeVersion, metrics, artifactUri, status

  Audited ai based real time fraud detection system run that records data, code, dependency, and evaluation lineage.

• ModelVersionmodelId, version, stage, schema, qualityGates, endpoint

  A promotable ai based real time fraud detection system model version with rollout state, contract, and rollback metadata.

Data flow

1. 1. Register and validate training dataThe ai based real time fraud detection system gateway records an immutable dataset version, schema, lineage, quality status, and privacy disposition.
2. 2. Build point-in-time featuresFeature workers join ai based real time fraud detection system inputs using event-time watermarks, prevent leakage, and publish the same feature contract for training and serving.
3. 3. Train and evaluate asynchronouslyThe orchestrator schedules ai based real time fraud detection system runs with checkpointed artifacts, reproducible environments, and metrics tied to the exact input versions.
4. 4. Gate and serve a model versionA registry compares ai based real time fraud detection system quality, bias, safety, and compatibility gates before canary or production rollout with an immediate rollback pointer.
5. 5. Monitor drift and learn from feedbackOnline inference records latency, errors, drift, and delayed labels so ai based real time fraud detection system retraining is evidence-driven rather than triggered by guesswork.

Deep dives and trade-offs

• Reproducibility and leakage preventionPin ai based real time fraud detection system data, feature, code, dependency, and model versions for every run. Use point-in-time joins and quarantine failed quality or privacy checks before training. Keep raw inputs and artifacts immutable so a result can be replayed after a dependency changes.
• Safe promotion and serving contractsSeparate ai based real time fraud detection system model registration from deployment and require signed artifacts plus schema compatibility. Use shadow traffic, canaries, rollback pointers, and per-version latency/error budgets. Return model version and feature freshness so clients can explain or reproduce a prediction.
• Drift, feedback, and costMeasure feature drift, prediction drift, label delay, and segment-level quality for ai based real time fraud detection system rather than only aggregate accuracy. Sample expensive inference and cap retraining concurrency with an explicit GPU or compute budget. Keep human corrections and delayed labels linked to the original prediction and model version.
• Batch versus online featuresPrefer a shared feature contract with batch backfills and a low-latency online serving path for decisions that need freshness. Two independently defined transformations create training-serving skew and hard-to-debug regressions.
• Synchronous versus asynchronous inferenceKeep interactive ai based real time fraud detection system inference synchronous within a strict budget and queue large or expensive jobs. A request path that waits for model loading, enrichment, or retraining turns downstream slowness into an outage.
• Global model versus segment modelsStart with one versioned model and add segment-specific models only when quality or policy evidence justifies the operational cost. Many simultaneously active versions multiply monitoring, rollback, and data-lineage burden.