How We Achieved Sub-100ms Email Queuing at 50M Emails per Day

For the first year of PostaSend's operation, our queuing layer was built on Redis. The design was simple: API servers pushed jobs onto sorted sets, and a pool of worker processes polled for new work on a 100ms interval. This worked well at low volume, but as we approached 10 million emails per day, we started seeing latency spikes at P99 that we could not explain with the CPU and memory metrics alone. The culprit, as it turned out, was lock contention on the Redis sorted set operations during burst traffic.

The solution we evaluated were Apache Kafka, RabbitMQ, and a move to AWS SQS. We ruled out RabbitMQ because we needed replay capabilities for audit trails. We ruled out SQS because the 300-message-per-second limit per queue without sharding would require significant application-layer complexity. Kafka won on the combination of throughput, replayability, and consumer group semantics that map cleanly onto our multi-tenant isolation model.

The migration took three months end-to-end. We ran Kafka in shadow mode alongside Redis for six weeks, comparing consumer lag and latency distributions before we started shifting production traffic. The move to Kafka eliminated P99 spike entirely — our P99 queuing latency went from 340ms at peak to 47ms, and P50 dropped from 95ms to 12ms. Total queue throughput ceiling increased from roughly 8,000 messages/second to over 200,000 messages/second per partition.

The lessons we took from this migration: instrument your queue depth, consumer lag, and individual message latency separately from the start. Redis is excellent for low-volume queuing but its single-threaded command processing becomes a bottleneck under bursty write patterns. If you are building anything that will eventually need replay semantics or consumer group isolation, start with Kafka — the operational overhead is more than offset by the architectural flexibility.