Distributed Email Placement Detection Platform

An event-driven, queue-based system for evaluating where outbound email lands — Inbox, Spam, Promotions, or undelivered — across multiple email service providers, under strict per-account sending quotas and at scale.

1. Executive Summary

Email deliverability is invisible until it fails. A sender can dispatch thousands of legitimate messages and silently have most of them filtered into Spam, with no signal that anything is wrong. The Email Placement Detection Platform solves this by sending controlled test emails into a network of monitored seed mailboxes across major providers (Gmail, Google Workspace, Outlook/Microsoft 365, Yahoo, Zoho), then determining exactly where each message landed and why.

I owned the backend architecture: a task-driven, queue-based distributed pipeline that converts every unit of work — sending an email, identifying its placement, scoring spam signals, gathering domain reputation — into discrete tasks, then schedules and executes them under hard per-account daily quotas.

Scale and shape of the system: designed to process tens of thousands of tasks per day (the overwhelming majority being send + placement-detection pairs), across an average of ~120 seed mailboxes per test, with the architecture deliberately built to scale horizontally well beyond that ceiling.

Key technical achievements:

• A Task Holder → Queue transition engine that enforces quotas and fairness before work ever reaches the execution queue — the architectural centerpiece.
• Event-driven enqueue/dequeue that keeps the running system consistent as users pause tests, disconnect accounts, or change configuration mid-flight.
• Quota-aware scheduling that guarantees no email account ever exceeds its daily sending limit, even under concurrent load.
• Dependent vs. independent task execution modes to support both human-like sequential sending and parallel bulk sending.

Impact: a reliable, fair, horizontally scalable system where placement testing runs predictably, quotas are never violated, and the running state stays consistent through arbitrary user actions.

2. Business Problem

Cold outreach and lifecycle email only work if messages actually reach the inbox. Providers apply opaque, constantly shifting filtering rules; a domain that delivered fine yesterday can be throttled today. Teams sending at volume need an early-warning system that continuously answers a deceptively simple question: “Where is my email actually landing?”

Answering it well is hard for reasons that are fundamentally engineering problems, not product ones:

• Every provider must be respected as a rate-limited external system. Email accounts have daily sending limits. Exceeding them damages sender reputation — the exact thing the platform exists to protect. The system can never trade short-term throughput for quota violations.
• A single “test” is not one action. It fans out into many dependent steps: send an email, wait for delivery, locate it in the seed mailbox, classify placement, score spam signals, snapshot domain/IP reputation. These steps have ordering constraints and different execution semantics.
• Fairness is a first-class requirement. Many tests from many users share the same pool of sender accounts and quotas. One aggressive test must not starve others.