Back to blog
Engineering

Scaling to 10 Million Messages: Our Infrastructure Journey

How we built a system that handles 10 million messages per month with 99.9% uptime and sub-second response times.

VS

Varun Sharma

Founder

Dec 18, 202512 min read
Scaling to 10 Million Messages: Our Infrastructure Journey

The Growth Challenge

When we launched Agent Rush, we handled a few thousand messages per day. Now we process over 300,000 daily. Here's how we scaled without breaking.

Architecture Evolution

Phase 1: The Monolith (0-100K messages/month)

We started simple:

  • Single Node.js server
  • PostgreSQL database
  • Redis for caching
  • Deployed on a single EC2 instance
  • This worked great for our first customers. Simple to debug, easy to deploy.

    Phase 2: Service Split (100K-1M messages/month)

    As load increased, we split into services:

  • Gateway Service - Handle incoming webhooks
  • Processing Service - AI inference and response generation
  • Delivery Service - Send responses to channels
  • Each service could scale independently.

    Phase 3: Event-Driven (1M-10M messages/month)

    At scale, synchronous processing hit limits. We moved to events:

    Message In → Queue → Process → Queue → Deliver

    Benefits:

  • Automatic retry on failures
  • Smooth traffic spikes
  • Easy to add new processors
  • Key Technical Decisions

    1. Database Strategy

    We use a hybrid approach:

  • PostgreSQL - Customer data, agent configurations
  • Redis - Session state, rate limiting, caching
  • Vector DB - Semantic search for knowledge bases
  • 2. AI Inference

    Running LLMs at scale is expensive. Our approach:

  • Model caching and warm pools
  • Request batching where possible
  • Tiered models (fast for simple, powerful for complex)
  • 3. Multi-Region Deployment

    Indian users expect low latency. We run in:

  • Mumbai (primary)
  • Singapore (backup)
  • Automatic failover in < 30 seconds
  • Lessons Learned

    1. Observability is Non-Negotiable

    We track:

  • Request latency (p50, p95, p99)
  • Error rates by type
  • Queue depths
  • AI model performance
  • You can't fix what you can't see.

    2. Graceful Degradation

    When systems strain, we:

  • Shed non-critical load
  • Return cached responses when possible
  • Clearly communicate delays to users
  • 3. Chaos Engineering

    We regularly break things on purpose:

  • Kill random pods
  • Inject network latency
  • Simulate database failures
  • Better to find weaknesses in testing than production.

    Current Numbers

  • 10M+ messages/month processed
  • 99.95% uptime over the last year
  • < 200ms p95 latency for responses
  • 3 engineers maintaining infrastructure
  • Scale doesn't require a massive team—it requires smart architecture.

    Share this article
    VS

    Varun Sharma

    Founder

    Building the future of customer support at Agent Rush. Passionate about AI, product design, and creating delightful user experiences.