Case study // 04
Mass Mail Sender
Production email microservice for reliable, rate-limited campaign delivery at scale — built for real cloud constraints, not demos.
Role · Backend / systems engineer
Overview
Sending newsletters at scale without blocking HTTP, exceeding SES limits, or creating duplicate sends when workers fail is a systems problem. This headless microservice accepts JSON campaign payloads, fan-outs recipients through a durable queue, tracks delivery/bounce/complaint lifecycle, and exposes analytics APIs for ops control.
Architecture
API writes logs and enqueues jobs → Worker sends via AWS SES using cached templates → SNS webhooks update delivery outcomes → Analytics APIs aggregate campaign health. Processes can run API-only, worker-only, or combined for Railway deploys.
- BullMQ rate-limited pipeline aligned to SES throughput
- Redis claim-check for large templates
- Separable API / worker modes
- Healthchecks + graceful shutdown for safe deploys
Features
Challenges → Solutions
Duplicate sends from aggressive retries
Disabled auto-retry; pause on permanent errors after a production incident
Huge job payloads in Redis
Claim-check pattern for templates to protect memory
Unsafe deploys mid-campaign
Coordinated graceful drain of API + worker
Blind operations at scale
Monitoring abort/resume + statistics/export APIs
Tech stack
Positioning
Distributed systems and API product ownership — there is no browser UI in this repo. AuthN/Z and an admin dashboard are intentional roadmap items, not hidden claims.
Next