Black Friday E-commerce: How to Handle 100k Emails/h Without Crashing
On Black Friday, an e-commerce shop sends in 4 hours what it normally sends in a month. Order confirmations, shipping notices, abandoned cart recoveries. Here is how to survive.
Between 18:00 and 22:00 on Black Friday, a mid-size e-commerce site ships more email than in the whole previous month. Order confirmations spike 50x, shipment notifications follow on Monday, abandoned cart recoveries run continuously. Any weakness in your email infrastructure surfaces immediately: rate limits, connection pools, retry storms, receiver throttling, suppression list corruption.
This is the playbook for surviving the four hours that matter. Most of it generalises to any high-volume event: Cyber Monday, big sale launches, product reveals.
The Volume Math
For a shop doing 50,000 orders on Black Friday, expect:
- 50,000 order confirmations within 4 hours = ~12,500/hour peak.
- ~10,000 abandoned cart emails (within 1h of abandonment).
- ~30,000 shipping notifications spread over Mon-Wed.
- ~10,000 "your order is on the way" updates.
- ~5,000 password resets (people log in after months).
- Plus marketing blasts (50-200k recipients) during the event.
Peak hour can hit 30,000-50,000 messages/hour for transactional alone, and 100,000+/hour if marketing overlaps. Per-second rates of 30-60 are normal at peak.
Step 1: Pre-Warm Your Sending IPs
If your normal volume is 100k/month, Black Friday will push 500k+ in 4 hours. Receivers see this as a 100x spike and apply rate limiting aggressively. Pre-warm by ramping your normal volume 50% the week before, 100% the day before. Receivers want to see a gradient, not a step.
⚠️ Warning: A Black Friday cold spike is one of the top three reasons IPs land on Spamhaus in November. Pre-warm or accept the blocklist risk.
Step 2: Separate Transactional from Marketing
Even if you normally co-mingle, separate on Black Friday. Two different SMTP credentials, ideally two different sending subdomains.
tx.shop.example.com: order confirmations, shipping, password resets. Must reach the inbox.news.shop.example.com: marketing blasts, retention campaigns. Reputation can take a hit without affecting transactional.
This is the single most important architectural decision. If your marketing blast triggers complaints, transactional reputation is shielded.
Step 3: Per-Receiver Throttling
Major receivers throttle by connection count and message rate per IP:
| Receiver | Conns per IP | Messages/sec safe |
|---|---|---|
| Gmail | 5 | 10-15 |
| Outlook | 3 | 5-10 |
| Yahoo | 5 | 10 |
| Apple iCloud | 3 | 5 |
| Italian incumbents | 2 | 3 |
Exceed and receivers reply 421/450 and start tarpitting your connections. The right pattern is per-recipient-domain queues, not a single global queue.
Step 4: Queue Depth and Workers
Provision worker capacity for 4x normal peak. If your queue worker can do 100 sends/sec, you need 4-8 workers running for Black Friday. Test in staging.
php artisan horizon:status # for Laravel
sidekiq -c 25 -q emails # for Ruby
celery worker --concurrency=25 # for PythonSet queue retention long enough to recover from a multi-hour outage: 24 hours minimum. Otherwise a delayed worker means lost messages.
Step 5: Idempotency Everywhere
On Black Friday, retries from worker restarts are guaranteed. Without idempotency keys, every retry is a duplicate order confirmation. Customer service drowns. Add idempotency keys derived from order ID:
{
"to": "buyer@example.com",
"subject": "Order #12847 confirmed",
"idempotency_key": "order-confirm:12847:v1"
}Step 6: Bounce Handling Backpressure
Bounce processing also spikes on Black Friday. Some receivers send DSN bounces with a 30-60 minute delay. Your bounce handler must not lock the send path. Use a separate worker pool and consume the bounce queue with idempotent processing.
Step 7: Suppression List Sanity
The night before Black Friday is the worst possible time to re-enable suppressed recipients to "boost the marketing list". Just don't. The complaint rate from re-activated hard bounces will blacklist you mid-event.
💡 Tip: Freeze the suppression list two weeks before Black Friday. Any "we should add these back" requests are deferred until December.
Step 8: Monitoring During Event
Have these dashboards on a dedicated screen:
- Sends per minute (per stream).
- Queue depth per worker pool.
- Bounce rate per receiver domain.
- Postmaster Tools spam rate (refresh every 15 min).
- Blacklist status of every sending IP.
- Customer service ticket volume on email keywords.
Step 9: Mid-Event Triggers
Pre-decide your "kill switch" thresholds. Examples:
- Spam rate > 0.3%: pause the marketing stream.
- Bounce rate > 5% on one receiver: pause that recipient domain for 15 min.
- Any blacklist hit: halt the IP, route via fallback.
- Queue depth > 30 min wait: spin up more workers.
Pre-decided thresholds avoid mid-event debate. They become the on-call playbook.
Step 10: Day-After Cleanup
The Sunday after Black Friday:
- Review bounce log for new hard bounces; suppress.
- Reconcile orders vs confirmations sent; identify any missed sends.
- Check Postmaster trends; compare reputation to pre-event baseline.
- Postmortem any incident.
The "Just-In-Case" List
Things to have ready at 17:00 on the day:
- Fallback IP unused, warm, ready to take traffic.
- Pre-drafted incident comms.
- Customer service script for "I didn't get my confirmation".
- Direct contact for your SMTP provider's on-call.
- Internal Slack channel with engineering + ops + customer service.
What Goes Wrong Most Often
- Marketing accidentally sends to "all customers" instead of "Black Friday subscribers", complaints spike, transactional gets caught in the same reputation drop because the team co-mingled IPs.
- Worker pool sized for normal load; queue backs up, customers complain about delayed confirmations, support escalates to engineering, engineering scales workers under stress.
- One country/receiver throttle goes unhandled; 30% of customers in that country get their confirmation 4 hours late.
- Suppression list reactivated the day before; complaints spike, IP gets listed at 19:30.
All four are 100% preventable with the patterns above.
Closing
Black Friday email is an exercise in pre-planning. Architecture, capacity, separation of streams and idempotency must all be in place before 17:00 on the day. Target SMTP's Send-Time Firewall enforces the per-receiver throttling, idempotency and stream separation automatically, and the platform pre-warms IPs based on the historic week-over-week ramp. If you are running Black Friday on your own stack this year, the patterns in this article are the floor — not the ceiling.