Email Service — Naive (Synchronous SMTP)

Designing an email delivery service is one of the most practical system design interview questions because it forces candidates to reason about the tension between synchronous simplicity and asynchronous scalability. The naive synchronous SMTP approach is where every candidate should start — it establishes the baseline that makes the improvements in queue-based and pipeline architectures measurable and concrete.

The core challenge is accepting an email via REST API and delivering it to the recipient's mail server via SMTP. In the naive approach, this is done synchronously: the EmailService opens an SMTP connection to the recipient's MX server, performs the EHLO/MAIL FROM/RCPT TO/DATA handshake, waits for the remote server to accept the message, and returns the HTTP response only after the SMTP transaction completes. This means every API call blocks for the full SMTP round-trip — typically 50-500ms depending on the receiving ISP, DNS MX lookup time, TLS negotiation, and the remote server's processing speed.

The synchronous approach has a hard throughput ceiling determined by the product of concurrent threads and SMTP latency. With 5 pods running 50 threads each (250 concurrent connections) and an average SMTP latency of 200ms, the theoretical maximum is 1,250 emails per second. In practice, SMTP latency variance (p99 exceeds 500ms when remote ISPs are slow or throttling) reduces effective throughput to approximately 100-500 emails per second before thread pool exhaustion causes cascading failures. The service simply runs out of threads waiting for SMTP responses.

Beyond the throughput ceiling, the naive approach has critical deliverability problems. There is no suppression list, so the service sends to addresses that have previously hard-bounced (invalid mailbox, domain does not exist). ISPs track per-sender-IP bounce rates and blacklist senders exceeding approximately 5%. Within days of sustained traffic, the sending IP will be blacklisted by Gmail, Yahoo, and Outlook, effectively killing deliverability. There is no DKIM/SPF/DMARC signing, so most ISPs classify emails as potential phishing and route them to spam. Without these authentication headers, deliverability drops from 99% (properly authenticated) to under 50%.

There is no retry logic — if the SMTP connection fails due to a temporary ISP issue (soft bounce, 421 response), the email is permanently lost. Production email services retry soft bounces with exponential backoff over 72 hours. The naive approach returns an error to the caller and moves on. There is no template engine, so the caller must provide fully rendered HTML in every API request, making bulk campaigns impractical.

This template makes the SMTP bottleneck visible and quantifiable. Run the simulation at increasing RPS and watch the EmailService thread pool saturate while the database sits idle. The comparison with the Queue-based and Pipeline variants provides the concrete numbers to support the discussion of async decoupling, suppression, and authentication that interviewers expect.

Email service design appears in interviews at Amazon (SES), Google (Gmail infrastructure), Microsoft (Outlook), Mailchimp, SendGrid, Twilio, and Postmark. Interviewers expect candidates to start with synchronous SMTP, identify the blocking I/O bottleneck, and propose async queue-based delivery as the first optimization — then discuss suppression lists, DKIM signing, and IP reputation management for the advanced variant.

The naive email service is a four-component linear architecture: Client, Load Balancer, EmailService, and PostgreSQL database. There is no cache, no event stream, no worker pool, and no separation between the API acceptance and SMTP delivery phases.

All traffic enters through the Load Balancer, which distributes requests across EmailService pods using round-robin. The Load Balancer adds approximately 1.5ms of routing latency and supports up to 10,000 concurrent connections — well above the system's actual ceiling, which is determined by the EmailService thread pool and SMTP latency. Both email sends and status queries flow through the same LB and service.

The EmailService is a monolithic REST API running on 5 pods with 50 threads each (250 total concurrent connections). It handles two operations: (1) send email — validate the request (from, to, subject, body_html), write a pending record to EmailDB, open a synchronous SMTP connection to the recipient's MX server, deliver the email, update the DB record with the result, and return the HTTP response; (2) status query — look up the email record by message_id and return the delivery status (pending, sent, failed). The critical bottleneck is the synchronous SMTP call in the send path. Every thread that handles a send request is blocked for 50-500ms waiting for the remote mail server to respond. This means the effective throughput is bounded by (thread_count / avg_smtp_latency_seconds).

PostgreSQL stores a single table: emails. Each email gets a row written on submission with status=pending (INSERT, ~20ms) and updated after SMTP delivery with status=sent or status=failed (UPDATE, ~15ms). The database is not the bottleneck — at 100 emails/sec, it handles only 200 queries/sec (one INSERT + one UPDATE per email), well within a single PostgreSQL instance's capacity. The bottleneck is entirely in the SMTP I/O path.

The system has no redundancy at any layer. A single PostgreSQL primary handles all reads and writes. There is no read replica, no cache, and no failover. If the database goes down, both sends and status queries fail. If SMTP connectivity is lost (DNS failure, network partition), all send threads block until timeout (30 seconds), exhausting the thread pool and causing the service to stop accepting new requests entirely.

The concrete scaling ceiling is approximately 100-500 emails per second sustained, depending on the distribution of recipient ISPs. ISPs with fast SMTP responses (Gmail averages 80ms) allow higher throughput than ISPs with slow responses (some corporate mail servers take 500ms+). At peak load, thread pool exhaustion manifests as HTTP 503 responses to new callers while all threads are blocked on SMTP I/O.