Scaling Microservices with RabbitMQ: Lessons from PROCASH

Building a fintech platform like PROCASH comes with unique engineering challenges. When we launched the loyalty reward system, we severely underestimated the volume of simultaneous transactions during peak bank hours.

The Scaling Bottleneck

As our user base grew, we noticed significant lag in transaction confirmation times. Our monolithic API endpoints were processing validation, bank API calls, and ledger updates in a single synchronous request-response cycle. During peak hours, this caused timeouts and cascading failures.

"We realized that the user didn't need the transaction to be finalized instantly, but they needed an immediate acknowledgment that the process had started."

Why RabbitMQ?

We evaluated Kafka, Redis Streams, and RabbitMQ. Our decision came down to: operational simplicity, support for message acknowledgment, and the maturity of the NestJS integration via @nestjs/microservices.

Queue Architecture

We designed three core queues:

• transaction.created -- handles initial validation
• transaction.bank_api -- communicates with BRI banking APIs
• transaction.ledger -- finalizes database writes and notifications

Implementation Details

The producer emits a message and immediately returns a 202 Accepted response. Consumer workers run as separate microservice instances and scale horizontally.

// Producer -- emit and return immediately
async createTransaction(dto: CreateTransactionDto) {
  this.client.emit('transaction.created', dto);
  return { status: 'accepted' };
}

Dead Letter Queues

Any message that failed processing three times was routed to a transaction.failed queue for manual review, giving our ops team full visibility without data loss.

Results and Future Outlook

After deploying the message-driven architecture, transaction throughput increased by over 400% while perceived latency dropped from 4.2 seconds to under 200ms. We plan to introduce Kubernetes-based auto-scaling for consumer workers next.