Design a Resilient Bot Defense & Sybil-Resistant Registration Architecture — Production Case Study

1. Problem Statement & Mission

System Mission

Design the ingress protection and anti-abuse architecture for a high-growth developer platform (e.g. AI algorithmic mastery & coding sandbox, cloud compute provider, or developer API) offering free compute coins upon signup and referral bonuses ($+25\text{ coins}$) per colleague invited.

The system must withstand coordinated bot attacks generating up to 500,000 automated registration attempts per hour, eliminate compute token farming, protect email sender reputation on Amazon SES ($< 2\%\text{ bounce rate}$), and preserve zero-friction onboarding for legitimate software engineers.

Functional Requirements

1. Frictionless Human Registration: Legitimate engineers must sign up in $< 3\text{ seconds}$ without solving visual puzzles or image captchas.
2. Automated Bot Interception: Intercept and neutralize headless browser clusters (Playwright, Puppeteer, Selenium), residential proxy networks, and disposable email pools.
3. Sybil-Resistant Referral Qualification: Referrer rewards unlock only when referred accounts complete authentic platform engagement milestones.
4. Email Reputation Protection: Prevent mass email bombing through email verification throttles and throwaway inbox filtering.

Non-Functional Requirements (SLAs & SLOs)

• Edge Latency Overhead: $\le 15\text{ ms}$ for legitimate users at the edge layer.
• False Positive Rate: $< 0.01\%$ (legitimate engineers must never be falsely blocked).
• High Availability: $99.99\%$ uptime for the authentication and registration service.

2. Capacity & Scale Estimation (Back-of-the-Envelope Math)

Attack Surge Volume

• Peak Attack Rate: $500,000\text{ registration attempts / hour} \approx \mathbf{140\text{ signups / sec}}$.
• Legitimate Peak Traffic: $50,000\text{ signups / day} \approx 5\text{ - }20\text{ signups / sec}$.
• Peak Ingress Load during Surge: $\approx \mathbf{160\text{ requests / sec}}$ directed at /api/auth/signup.

Database & Cache Sizing

• Active IP / Subnet Rate Limits in Redis:
  • Track active IPs over a 15-minute sliding window.
  • $140\text{ req/sec} \times 900\text{ sec} = 126,000\text{ unique IP keys}$.
  • Each Redis sliding window key (Sorted Set of timestamps): $\approx 200\text{ bytes}$.
  • Memory Required: $126,000 \times 200\text{ bytes} \approx \mathbf{25\text{ MB RAM}}$ (negligible footprint for ElastiCache cache.t4g.micro or Redis cluster).
• Disposable Email Domain Bloom Filter:
  • $50,000$ disposable domains with $0.1\%$ false positive probability.
  • Memory: $m = -\frac{n \ln p}{(\ln 2)^2} \approx \mathbf{90\text{ KB}}$ (in-memory, sub-millisecond lookup).