##### Question Design an event system that can manage at least **1,000,000 concurrent events** and send notification emails to every registered participant of each event (e.g., reminders, schedule changes/cancellations, post-event follow-ups). Walk through the full design and address the following: 1. **Core APIs** — create/update/cancel an event, register a participant, and schedule or immediately trigger emails for an event (include idempotency on writes). 2. **High-level architecture** — the services and message-bus/queue topology that turn an event trigger into per-recipient emails. 3. **Data model and storage strategy** — schemas, indexes, partitioning/sharding, and retention; relational vs. NoSQL trade-offs. 4. **End-to-end email delivery pipeline** — producers, queues, consumers, fan-out, batching, retries, idempotency keys, deduplication, and bounce/complaint handling via an ESP. 5. **Capacity estimates** — QPS, fan-out per event, and peak email throughput, with the math behind them. 6. **Scalability** — partitioning, horizontal autoscaling of workers, and backpressure. 7. **Scheduling strategies** — time-based reminders vs. event-driven triggers, a distributed scheduler, and how to avoid thundering-herd spikes. 8. **Rate limiting and quotas** — across tenants, ESP providers, and recipient domains; provider-quota adherence. 9. **Delivery semantics** — at-least-once vs. exactly-once, dead-letter queues, and reprocessing. 10. **Failure handling and reliability** — retries with backoff, the transactional outbox pattern, and how the system recovers from a regional outage or provider throttling. 11. **Observability** — metrics, SLOs, tracing, and alerting. 12. **Abuse prevention and compliance** — unsubscribe/suppression lists, double opt-in, CAN-SPAM/GDPR. 13. **Multi-region availability and disaster recovery**, with the consistency trade-offs involved. 14. **Cost considerations** — a rough estimate and a managed-services-vs-self-hosting discussion. Walk through one concrete failure scenario (e.g., a regional outage or provider throttling) and explain how the system degrades and recovers.

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design Event Email System states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a medium difficulty System Design question, commonly asked during Onsite rounds at StubHub.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at StubHub during technical interviews.

Design Event Email System | StubHub Interview Question

Design Event Email System

Design an event system that can manage at least 1,000,000 concurrent events and send notification emails to every registered participant of each event (e.g., reminders, schedule changes/cancellations, post-event follow-ups). Walk through the full design and address the following:

Core APIs — create/update/cancel an event, register a participant, and schedule or immediately trigger emails for an event (include idempotency on writes).
High-level architecture — the services and message-bus/queue topology that turn an event trigger into per-recipient emails.
Data model and storage strategy — schemas, indexes, partitioning/sharding, and retention; relational vs. NoSQL trade-offs.
End-to-end email delivery pipeline — producers, queues, consumers, fan-out, batching, retries, idempotency keys, deduplication, and bounce/complaint handling via an ESP.
Capacity estimates — QPS, fan-out per event, and peak email throughput, with the math behind them.
Scalability — partitioning, horizontal autoscaling of workers, and backpressure.
Scheduling strategies — time-based reminders vs. event-driven triggers, a distributed scheduler, and how to avoid thundering-herd spikes.
Rate limiting and quotas — across tenants, ESP providers, and recipient domains; provider-quota adherence.
Delivery semantics — at-least-once vs. exactly-once, dead-letter queues, and reprocessing.
Failure handling and reliability — retries with backoff, the transactional outbox pattern, and how the system recovers from a regional outage or provider throttling.
Observability — metrics, SLOs, tracing, and alerting.
Abuse prevention and compliance — unsubscribe/suppression lists, double opt-in, CAN-SPAM/GDPR.
Multi-region availability and disaster recovery , with the consistency trade-offs involved.
Cost considerations — a rough estimate and a managed-services-vs-self-hosting discussion.

Walk through one concrete failure scenario (e.g., a regional outage or provider throttling) and explain how the system degrades and recovers.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Design Event Email System

Core APIs — create/update/cancel an event, register a participant, and schedule or immediately trigger emails for an event (include idempotency on writes).
High-level architecture — the services and message-bus/queue topology that turn an event trigger into per-recipient emails.
Data model and storage strategy — schemas, indexes, partitioning/sharding, and retention; relational vs. NoSQL trade-offs.
End-to-end email delivery pipeline — producers, queues, consumers, fan-out, batching, retries, idempotency keys, deduplication, and bounce/complaint handling via an ESP.
Capacity estimates — QPS, fan-out per event, and peak email throughput, with the math behind them.
Scalability — partitioning, horizontal autoscaling of workers, and backpressure.
Scheduling strategies — time-based reminders vs. event-driven triggers, a distributed scheduler, and how to avoid thundering-herd spikes.
Rate limiting and quotas — across tenants, ESP providers, and recipient domains; provider-quota adherence.
Delivery semantics — at-least-once vs. exactly-once, dead-letter queues, and reprocessing.
Failure handling and reliability — retries with backoff, the transactional outbox pattern, and how the system recovers from a regional outage or provider throttling.
Observability — metrics, SLOs, tracing, and alerting.
Abuse prevention and compliance — unsubscribe/suppression lists, double opt-in, CAN-SPAM/GDPR.
Multi-region availability and disaster recovery , with the consistency trade-offs involved.
Cost considerations — a rough estimate and a managed-services-vs-self-hosting discussion.

Walk through one concrete failure scenario (e.g., a regional outage or provider throttling) and explain how the system degrades and recovers.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Design Event Email System

Quick Overview

Design Event Email System

Design Event Email System

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP

Design Event Email System

Quick Overview

Design Event Email System

Design Event Email System

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP