Event-Driven Messaging System

Relevant source files

The following files were used as context for generating this wiki page:

• lib/event-emitter.ts
• lib/inngest.ts
• lib/workflow-client.ts
• REAL_TIME_BANKING_SUMMARY.md
• PROJECT_COMPLETION_SUMMARY.md
• PHASE_1_COMPLETION_SUMMARY.md

The Event-Driven Messaging System in BankChase is a production-ready, asynchronous architecture designed to handle high-performance banking operations. The system decouples primary business logic, such as fund transfers, from secondary side effects like SMS alerts and email notifications, ensuring sub-100ms response times for critical API endpoints.

This architecture leverages a combination of local Node.js EventEmitter patterns, Upstash Redis for event distribution, and durable workflow engines (Inngest and QStash) to ensure resilience and observability across the platform.

Sources: REAL_TIME_BANKING_SUMMARY.md, PHASE_1_COMPLETION_SUMMARY.md

System Architecture

The messaging system is structured to provide non-blocking execution by utilizing an event-consumer pattern. When a high-priority event (like a transfer initiation) occurs, the system validates the request and publishes an event before immediately returning a response to the client. Background consumers then pick up these events to perform long-running tasks.

Event Propagation Flow

The flow ensures the client does not wait for third-party service latency (e.g., SMS delivery or email sending).
Sources: REAL_TIME_BANKING_SUMMARY.md, lib/event-emitter.ts

Core Components

Event Emitter and Distribution

The system utilizes a centralized event emitter to manage banking events. It supports local execution for performance and Redis-based distribution for scalability across serverless environments.

Component	Description	Reference File
Local Emitter	Node.js EventEmitter for internal process signals.	lib/event-emitter.ts
Upstash Redis	Acts as the message broker for event distribution and state.	REAL_TIME_BANKING_SUMMARY.md
Event Types	transfer.initiated, transfer.completed, transfer.failed.	REAL_TIME_BANKING_SUMMARY.md

Durable Workflows

For complex, multi-step messaging sequences (e.g., onboarding emails or multi-channel notifications), the system uses Upstash Workflow and Inngest. These provide automatic retries and state persistence.

Implementation Details

Transfer Event Logic

The system implements a double-entry ledger for financial compliance, triggered through event-driven processors. When a transfer is initiated, the Transfer API performs an immediate lock in the ledger and returns a 202 Accepted status, while the actual movement and notifications happen asynchronously.

// Example Workflow Payload Structure
export interface TransactionPayload {
  transactionId: string;
  userId: string;
  type: 'transfer' | 'deposit';
  amount: number;
  userEmail: string;
}

Sources: lib/workflow-client.ts:8-14, PHASE_1_COMPLETION_SUMMARY.md

Resilient Delivery (Retry Mechanism)

The system employs exponential backoff for messaging failures, particularly for SMS and Email gateways:

• Initial attempt: Immediate.
• Retry 1: 5 seconds delay.
• Retry 2: 10 seconds delay.
• Retry 3: 20 seconds delay.
• Max Retries: 3 attempts before logging as a hard failure.

Sources: REAL_TIME_BANKING_SUMMARY.md

API Endpoints and Configuration

The messaging system is managed through several specialized endpoints for initialization and status tracking.

Endpoint	Method	Purpose
/api/init	GET	Initializes event systems and consumers on app startup.
/api/workflows/notification	POST	Triggers a multi-channel notification workflow.
/api/transfers/status	GET	Polls the status of an event-driven transaction.
/api/admin/health	GET	Monitors alert queue depth and SMS success rates.

Sources: REAL_TIME_BANKING_SUMMARY.md, PROJECT_COMPLETION_SUMMARY.md

Summary

The Event-Driven Messaging System is a critical infrastructure component of BankChase, enabling high throughput (up to 100K notifications/second) and sub-100ms response times. By utilizing Redis for state and durable workflows for execution, the system guarantees that banking notifications and transaction logs remain consistent even in the event of partial service failures.

Sources: REAL_TIME_BANKING_SUMMARY.md, PHASE_1_COMPLETION_SUMMARY.md