Microservices-Based Financial System

Overview

This project is a microservices-based financial system where all client requests are routed through an API Gateway. It includes authentication, user management, account handling, payments, and fund transfers. The system leverages event-driven communication with Kafka and Avro-based schema registry.

Some Parantheses

Normally jwt secrets needs to be in the keystore, but I am not adding it with this release because I want to stay away from questions like "where did this come from or where is this keystore? There is one more thing I need to clarify: you will see some code repeats between services. Most of it can be collected in a shared library, but I didn't add a shared library because I don't want to bother explaining "unseen code", and if anyone tries to work on these project, they can configure keystores themselves.

Architecture

Services

The system consists of the following services:

Core Infrastructure Services:

• API Gateway: Routes all incoming requests and handles JWT authentication.

• Eureka Service Registry: Manages service discovery.

• Authentication Service: Handles user registration, login, and JWT token management.

Business Services:

• User Service: Stores user details and publishes user registration events.

• Account Service: Manages user accounts, balance, and account status.

• Payment Service: Processes payments and synchronizes account data.

• Fund Transfer Service: Handles fund transfers and ensures transaction consistency.

Event-Driven Communication

All services use Kafka to produce and consume events as Avro records. The system follows the Outbox Pattern, where events are stored in an outbox table before being published.

Outbox Pattern Workflow

1. A service writes an event to the outbox table with a PENDING status.

2. The Event Service periodically scans for pending events.

3. Events are published to Kafka and marked as PUBLISHED.

4. If event processing fails, the consumer republishes the event as FAILED.

Authentication & Security

• JWT Handling: Tokens are stored in HttpOnly cookies.

• Gateway Validation: The API Gateway validates JWT tokens using shared keystores.

Data Flow

1. User Registration

   • The user registers via the API Gateway.

   • The Authentication Service stores credentials and creates a JWT.

   • The User Service persists user details and emits a UserRegistered event.

   • The Account Service and Payment Service consume this event to initialize user accounts.

2. Fund Transfer

   • The Payment Service initiates a transaction and builds a PaymentCreated event.

   • The Fund Transfer Service consumes this event and decides if the payment is valid.

   • If valid, it emits a PaymentProcessed event.

   • The Account Service updates balances accordingly.

Technology Stack

• Spring Boot (Microservices framework)

• Kafka (Event streaming)

• PostgreSQL & MongoDB (Databases)

• Avro (Schema registry for events)

• Docker (Containerization)

• JWT (Authentication)

• API Gateway (Routing & authentication)

Future Improvements

• Implement Dead Letter Queue (DLQ) for handling failed events.

• Implement scheduled sync for Account Sync Service.

• Introduce rollback mechanisms for failed fund transfers.

Running the Project

To run the project, ensure you have Docker installed and execute:

# Start all services using Docker Compose
docker-compose up -d

For local development, run services individually via Maven:

mvn spring-boot:run

---