Fahim Hasnain Fahad

Posted on Jun 4

Scaling to 10M Users with Event-Driven Architecture

#node #javascript #10m

🌟 The Day Our Server Crashed 🌟

Remember that feeling when your application suddenly crashes? That's exactly what happened to me last month. 😱

I was sipping my morning coffee ☕ when my phone exploded with notifications. Our startup's Node.js app had completely crashed after a marketing campaign brought in 50,000 new users overnight. What should have been a celebration turned into a nightmare.

"But I built this with Express! It should handle the load!" I remember telling my senior developer, Maria.

She smiled knowingly. "Time to learn about event-driven architecture, my friend."

🔍 Understanding the Problem

Our monolithic Express app was processing everything synchronously - user signups, email notifications, analytics tracking, and data processing were all happening in a single request-response cycle:

app.post('/signup', async (req, res) => {
  // This does EVERYTHING in one request! 😵
  await createUser(req.body);
  await sendWelcomeEmail(req.body.email);
  await trackSignupAnalytics(req.body);
  res.send({ success: true });
});

🧩 Enter Event-Driven Architecture

Maria explained that event-driven architecture is like a relay race 🏃‍♀️ where each runner (service) does their part and passes the baton (event) to the next runner, rather than having one person run the entire race.

🔥 The Core Concept

Instead of doing everything at once, we:

Publish events when something happens
Let other parts of the system subscribe to events they care about
Process those events asynchronously

⚡ Transforming Our App

We refactored our code to use events:

// Now we just publish an event! 🎉
app.post('/signup', async (req, res) => {
  await createUser(req.body);
  eventEmitter.emit('user.created', req.body);
  res.send({ success: true });
});

🎯 The Architecture Evolution

Before	After
Synchronous processing	Asynchronous event handling
Single point of failure	Distributed resilience
Tight coupling	Loose coupling
Linear scaling	Horizontal scaling
5-second response times	200ms response times

📊 Results After 30 Days

Metric	Before	After	Improvement
Max concurrent users	5,000	250,000	50x
Average response time	2,500ms	120ms	20x faster
Server costs	$1,200/mo	$750/mo	37% cheaper
Uptime	97.2%	99.99%	2.79% increase

🛠️ Implementation Steps

Our journey to scaling involved these key steps:

Identify bottlenecks in our monolithic app
Decouple components using an event bus
Deploy microservices for heavy processing tasks
Implement circuit breakers for resilience

🔧 Technology Stack We Used

Node.js + Express for API services
Kafka for event streaming at scale
Redis for pub/sub in smaller services
MongoDB for document storage
PostgreSQL for relational data

💡 Pro Tip: Start Simple!

You don't need Kafka right away! Begin with Node.js's built-in EventEmitter:

const EventEmitter = require('events');
const eventBus = new EventEmitter();

This gives you the event-driven pattern without the infrastructure complexity. Later, you can swap in more robust solutions without changing your core logic!