How would you architect personalized email and coupon delivery at scale?

What's really being asked

The interviewer wants to see if you understand how to decouple dynamic content generation from high-volume delivery. Specifically, they care about idempotency, atomic inventory reservation, and graceful degradation under load. Generating unique single-use coupons introduces a scarce resource problem: if you retry a failed send or duplicate a job, you burn valid codes and anger finance. They also want to know you have handled real-world email constraints like ESP rate limits, bounce handling, and template rendering latency.

The full answer

A good answer hits four things in order. First, a template service that ingests user profiles and renders HTML or text greetings using a sandboxed engine, caching static partials to reduce compute. Second, a coupon microservice with an atomic reserve-and-mark flow, using a database row lock or compare-and-swap operation so each code moves from AVAILABLE to ISSUED exactly once, storing the mapping between user ID and code before any send attempt. Third, an idempotent job queue where each message has a deterministic ID derived from the campaign and user, allowing at-least-once retries without re-reserving a new coupon on every attempt. Fourth, a delivery layer that streams batches to the ESP, enforces per-domain rate limits, handles 4xx and 5xx responses, and consumes feedback loops for bounces and complaints.

The mistakes people make

Common wrong answers include generating the coupon inside the SMTP send call, which risks burning codes on network timeouts; storing coupons as plain text in the template database instead of a separate secured service; ignoring idempotency and allowing duplicate emails with different codes; and failing to mention rate limiting or warm-up schedules, which destroys deliverability. Another red flag is suggesting a single monolithic cron job that generates all emails synchronously, creating a single point of failure and memory bottleneck.

What usually comes next

Interviewers often ask how you would handle a partial outage where the ESP is down but coupons are already reserved; the correct pattern is to park jobs in a dead-letter queue and preserve the reserved codes rather than invalidating them. They may also ask about personalization beyond the greeting, such as product recommendations, which tests whether your template engine can accept arbitrary data schemas. Another follow-up is compliance: how do you honor unsubscribe requests instantly when a batch is already queued, which requires a pre-send eligibility check against a suppressed-user set.

A concrete example

Imagine a flash sale for one million users. Your campaign service partitions the audience into chunks of ten thousand. For each chunk, it calls the coupon service to bulk-reserve codes, writing user-code pairs into a pending-sends table with a campaign-scoped UUID. A worker pool picks up these records, renders templates with the reserved greeting and code, and enqueues delivery jobs with deterministic IDs. If an ESP webhook reports a hard bounce, you remove the address from the chunk and log the reserved code as unclaimed for reuse or write-off. If a worker crashes mid-batch, the deterministic job ID prevents re-rendering and re-sending when the job retries.