5 real Kafka interview questions asked at Stripe. Upvoted by engineers who cleared the loop. Covers System Design, Technical rounds.
Stripe
Hard
System Design round
KafkaPostgreSQLDistributed Systems
Design Stripe's webhook delivery system.
Stripe sends millions of webhooks per day to customer endpoints that can be slow, down, or buggy.
Cover: at-least-once delivery guarantees, retry with exponential backoff, ordering guarantees (or lack thereof), how to handle a customer endpoint that is down for 24h, and the dead-letter strategy.
↑ 79 upvotes · 77 engineers asked this · SDE2
Stripe
Hard
System Design round
Distributed SystemsKafkaPostgreSQL
Design Stripe's fraud detection system. For every payment, you must decide accept/decline in under 100ms using hundreds of signals. Cover: feature engineering, real-time ML scoring, rule engine, and how you minimise false positives (declined legitimate payments).
↑ 68 upvotes · 44 engineers asked this · SDE2
Stripe
Hard
System Design round
PostgreSQLKafkaDistributed Systems
Design Stripe's subscription billing system (Stripe Billing). Customers are charged on recurring intervals (monthly/annual) in different currencies, with proration for plan upgrades. Cover: invoice generation, dunning for failed payments, and SCA (Strong Customer Authentication) compliance.
↑ 63 upvotes · 40 engineers asked this · SDE2
Stripe
Medium
Technical round
3-6 yearsNode.jsSystem DesignKafka
Design a webhook delivery system that must guarantee at-least-once delivery to customer endpoints, with retries and backoff, without letting one slow customer endpoint block delivery to others.
↑ 31 upvotes · 14 engineers asked this · Senior SDE
Stripe
Hard
Technical round
3-7 yearsKafka
A Kafka consumer processing payment events crashes and restarts, re-reading the last uncommitted batch. How do you make the payment-processing logic itself idempotent, not just rely on Kafka?
↑ 22 upvotes · 13 engineers asked this · Senior SDE
Design Stripe's webhook delivery system.
Design Stripe's webhook delivery system.
Stripe sends millions of webhooks per day to customer endpoints that can be slow, down, or buggy.
Cover: at-least-once delivery guarantees, retry with exponential backoff, ordering guarantees (or lack thereof), how to handle a customer endpoint that is down for 24h, and the dead-letter strategy.
Design Stripe's fraud detection system. For every payment, you must decide accept/decline in under 100ms using hundreds of signals. Cover: feature engineering, real-time ML scoring, rule engine, and how you minimise false positives (declined legitimate payments).
Design Stripe's fraud detection system. For every payment, you must decide accept/decline in under 100ms using hundreds of signals. Cover: feature engineering, real-time ML scoring, rule engine, and how you minimise false positives (declined legitimate payments).
Design Stripe's subscription billing system (Stripe Billing). Customers are charged on recurring intervals (monthly/annual) in different currencies, with proration for plan upgrades. Cover: invoice generation, dunning for failed payments, and SCA (Strong Customer Authentication) compliance.
Design Stripe's subscription billing system (Stripe Billing). Customers are charged on recurring intervals (monthly/annual) in different currencies, with proration for plan upgrades. Cover: invoice generation, dunning for failed payments, and SCA (Strong Customer Authentication) compliance.
Design a webhook delivery system that must guarantee at-least-once delivery to customer endpoints, with retries and backoff, without letting one slow customer endpoint block delivery to others.
Design a webhook delivery system that must guarantee at-least-once delivery to customer endpoints, with retries and backoff, without letting one slow customer endpoint block delivery to others.
A Kafka consumer processing payment events crashes and restarts, re-reading the last uncommitted batch. How do you make the payment-processing logic itself idempotent, not just rely on Kafka?
A Kafka consumer processing payment events crashes and restarts, re-reading the last uncommitted batch. How do you make the payment-processing logic itself idempotent, not just rely on Kafka?