Bird
Raised Fist0

Design a Fraud Detection System - Real-Time Scoring, Rule Engine, Feature Store

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Apache Kafka

Ingest transaction event

Transaction event published to Kafka topic

Protocol:Kafka protocol
BeforeTransaction event generated by payment system, not yet persisted
AfterTransaction event durably stored in Kafka topic partition
Apache Flink

Consume and enrich event

Flink reads event, enriches with historical features from Cassandra

Protocol:Flink RPC and CQL
BeforeKafka topic contains raw transaction event
AfterEnriched event with features ready for rule evaluation
Apache Cassandra

Serve feature data

Cassandra returns user and transaction features for enrichment

Protocol:CQL
BeforeFeature data stored in Cassandra, not yet queried
AfterFeature data retrieved from Cassandra and combined with event in Flink
Rule Engine (Drools or custom)

Evaluate fraud rules

Rule Engine applies configured rules to enriched event data

Protocol:gRPC
BeforeEnriched event ready for rule evaluation
AfterRule evaluation results produced for scoring
Real-Time Scoring Service

Calculate fraud score

Scoring service computes risk score based on rule results

Protocol:REST API
BeforeRule evaluation results available
AfterFraud score computed and ready for alerting
Alerting & Downstream Integration

Send alert if fraud detected

Alerts sent to monitoring and downstream systems if score high

Protocol:REST API / Messaging
BeforeFraud score computed, no alert sent yet
AfterAlert dispatched to external systems for investigation
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│       Apache Kafka            │
│  (Event ingestion queue)      │
└──────────────┬────────────────┘
               │ Kafka protocol
               ▼
┌───────────────────────────────┐
│     Apache Flink              │
│ (Stream processing & feature  │
│   enrichment)                 │
└──────────────┬────────────────┘
               │ Flink RPC
               ▼
┌───────────────────────────────┐
│ Apache Cassandra              │
│ (Feature Store DB)            │
└──────────────┬────────────────┘
               │ CQL (Cassandra Query Language)
               ▼
┌───────────────────────────────┐
│ Rule Engine                  │
│ (Drools or custom rules)     │
└──────────────┬────────────────┘
               │ gRPC
               ▼
┌───────────────────────────────┐
│ Real-Time Scoring Service    │
│ (Fraud score calculation)    │
└──────────────┬────────────────┘
               │ REST API
               ▼
┌───────────────────────────────┐
│ Alerting & Downstream         │
│ Integration                  │
└───────────────────────────────┘
Design Rationale

This architecture processes transaction events in real-time for fraud detection. Events are ingested into Apache Kafka, ensuring durable, ordered storage. Apache Flink consumes these events, enriching them with historical features fetched from Apache Cassandra, the feature store. The enriched data is passed to a Rule Engine, which applies fraud detection rules. The results feed into the Real-Time Scoring Service that calculates a fraud risk score. Finally, alerts are generated and sent to downstream systems if suspicious activity is detected. This pipeline ensures low-latency, scalable fraud scoring with clear separation of concerns between ingestion, enrichment, rule evaluation, scoring, and alerting.

Primary Focus

✓

Practice

(1/5)
1. In a sharded CRDT counter system, what exactly breaks if the shard state replication mechanism fails silently for several minutes?
medium
A. Local shard increments continue, but the global aggregated count lags behind until replication resumes
B. All increments are lost because shards cannot merge without replication
C. The global counter value becomes permanently inconsistent and cannot be recovered
D. The system blocks all increments until replication is restored to maintain consistency

Solution

  1. Step 1: Understand replication role in CRDT counters

    Replication propagates shard states to other replicas for merging. Without it, shards cannot merge and increments are isolated.

  2. Step 2: Trace failure impact

    Without replication, increments on isolated shards are effectively lost from global view until replication resumes; no blocking occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Replication failure isolates shards, causing lost increments globally [check]
Hint: No replication -> isolated shards -> lost global increments [check]
Common Mistakes:
2. For delivering notifications to mobile devices at 10M+ scale, which architecture better handles intermittent connectivity and battery constraints?
medium
A. Use push notification services (APNs, FCM) with message TTL and retries managed by the platform
B. Use persistent gRPC streaming connections from server to device for real-time delivery
C. Use long polling HTTP connections from device to server to fetch notifications
D. Use SMS as the primary delivery channel for all notifications

Solution

  1. Step 1: Evaluate persistent connection approaches

    gRPC streaming (A) is unreliable on mobile due to network changes and battery constraints; long polling (C) wastes battery and bandwidth.

  2. Step 2: Consider platform push services and SMS

    Push services (B) handle retries and offline buffering efficiently; SMS (D) is costly and not suitable for all notifications.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Platform push services manage retries and offline buffering [check]
Hint: Use platform push services, not persistent streams on mobile [check]
Common Mistakes:
3. For the review system, which architecture better supports real-time aggregation of review scores for millions of listings with minimal latency, given that eventual consistency is acceptable?
medium
A. Use a stream processing system like Apache Flink to aggregate reviews in real-time
B. Use a relational database with complex joins and transactions for immediate consistency
C. Use batch processing with daily MapReduce jobs to update aggregated scores
D. Use a NoSQL document store with denormalized review aggregates updated on each write

Solution

  1. Step 1: Identify real-time aggregation needs

    Millions of listings require low-latency updates; immediate consistency is not mandatory.

  2. Step 2: Evaluate architectures

    Relational DB (A) is costly and slow at scale; batch jobs (C) have high latency; NoSQL denormalization (D) risks write amplification and stale data. Stream processing (B) provides scalable, low-latency aggregation with eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stream processing enables scalable real-time aggregation with eventual consistency [check]
Hint: Stream processing fits real-time aggregation with eventual consistency [check]
Common Mistakes:
4. For a search system with highly skewed term distributions and frequent query updates, which scoring approach is better and why?
medium
A. Use classic TF-IDF because it is simpler and faster to compute
B. Use raw term frequency only to avoid overhead of inverse document frequency
C. Use BM25 because it handles term saturation and document length normalization better
D. Use a vector space model with cosine similarity ignoring term frequency

Solution

  1. Step 1: Analyze term distribution and query update needs

    Skewed term distributions cause TF-IDF to overweight rare terms excessively; frequent updates require robust scoring.

  2. Step 2: Evaluate scoring methods

    BM25 accounts for term frequency saturation and normalizes by document length, improving relevance in skewed data; TF-IDF and raw TF lack these refinements; vector space ignoring TF loses relevance signals.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    BM25 handles skew and length normalization better than TF-IDF [check]
Hint: BM25 normalizes length and term saturation better than TF-IDF [check]
Common Mistakes:
5. At 10x scale, which component in an HTTP/3 deployment is most likely to become the bottleneck first and why?
hard
A. WebSocket servers because HTTP/3 does not support WebSockets natively
B. TLS handshake CPU load on servers due to QUIC's per-connection encryption overhead
C. UDP packet loss rate increases causing retransmissions and latency spikes
D. TCP connection limits because HTTP/3 uses TCP under the hood

Solution

  1. Step 1: Identify HTTP/3 transport and encryption

    HTTP/3 uses QUIC over UDP with built-in TLS encryption per connection, increasing CPU load for handshake and encryption at scale.

  2. Step 2: Eliminate other bottlenecks

    UDP packet loss is network-level, not server bottleneck; WebSockets are not natively supported by HTTP/3 but unrelated to scaling HTTP/3 itself; HTTP/3 does not use TCP.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    QUIC's per-connection TLS handshake CPU load limits HTTP/3 scale [check]
Hint: QUIC TLS handshake CPU load limits HTTP/3 scale first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard