Regis Pay is fictional payment processor created as an example of a event-driven microservice architecture project built with dotnet, making use of the Transactional Outbox pattern (with Azure Cosmos DB) and Event Sourcing pattern.

This diagram depicts the architecture of this solution.

• API: Represents the application programming interface that exposes endpoints for creating, updating, and deleting data.
• Change Feed Processor: Monitors changes to data (e.g., database records) and publishes events when changes occur.
• Event Consumer: Subscribes events and processes them (e.g., updating databases, sending notifications, etc.).

This sequence diagram shows how a payment would go travel through the system.

sequenceDiagram
actor Client
Client->> API: Create Payment
Note over API,Event Store: Persisting event to event store
API->>Event Store: Payment Initiated
Note over Event Store, Change Feed: Domain events
Event Store-->>Change Feed: Payment Initiated
Note over Change Feed, Message Broker: Publish integration events
Change Feed-->>Message Broker: Payment Initiated
Note over Message Broker, Consumer: Consume integration events
Message Broker-->>Consumer: Payment Initiated
activate Consumer
Note over Consumer, 3rd Party System: Handle integration event
Consumer->> 3rd Party System: Create Payment
Consumer->> Event Store: Payment Created
deactivate Consumer
Event Store-->>Change Feed: Payment Created
Change Feed-->>Message Broker: Payment Created
Message Broker-->>Consumer: Payment Created
activate Consumer
Consumer->> 3rd Party System: Settle Payment
Consumer->> Event Store: Payment Settled
deactivate Consumer
Event Store-->>Change Feed: Payment Settled
Change Feed-->>Message Broker: Payment Settled
Message Broker-->>Consumer: Payment Settled
activate Consumer
Consumer->> 3rd Party System: Send Notification
Consumer->> Event Store: Payment Completed
deactivate Consumer
Event Store-->>Change Feed: Payment Completed
Change Feed-->>Message Broker: Payment Completed

All components have been added to make the clear distinction how a payment flows through this architecture The same components from the previous diagram are included below and the new ones have been marked with asterisk(*).

• API: Represents the application programming interface that exposes endpoints for creating, updating, and deleting data.
• Event Store*: Where event data is persisted. In this example project Cosmos DB, other databases are available.
• Change Feed Processor: Monitors changes to data (e.g., database records) and publishes events when changes occur.
• Message Broker*: System used to forward on messages (integration events). Used the term Message Broker because RabbitMQ was used in this example, but this could easily be swapped out for servies like Azure Service Bus.
• Event Consumer: Subscribes events and processes them (e.g., updating databases, sending notifications, etc.).
• 3rd Party System*: Represents a thrid party system, either internally or externally.

There are three ways to get started and up and running.

• Azure Cosmos DB Emulator
• Docker Desktop - preferred docker solution used for .

1. Set the Regis.Pay.AppHost project as the start up project and run.
2. (optional) Navigate to Demo project and create a payment.

• Docker Desktop - preferred docker solution.

1. cd into the local folder and run the localSetup.ps1 from your terminal. This is to setup the cert on API docker container for HTTPS support.

.\localSetup.ps1

2. Then run docker compose

docker-compose up --build

3. (optional) Navigate to payment.http file in the local folder and create a payment.

This should run all the services as-well as all the required dependencies in a pre-configured working state.

The following prerequisites are required to build and run the solution. You can either install them individually or via docker:

• Azure Cosmos DB Emulator
• RabbitMQ

1. Run the solution from Visual Studio, Api, ChangeFeed and EventConsumer should be set up as the start up projects.

Once up and running you can test the solution by using the payment.http file to make a API request and observe the logs. As this solution uses CosmosDB and RabbitMQ, you can also inspect these systems to verify integration.

Here's an example gif showcasing the services running in docker and me manually submitting a payment request.

Observe the logs emitted as the payment goes through the services.

Alternatively if you have started the application via the Aspire host you can navigate to the demo project and create a payment from the demo UI.

Core infrastructure technologies in this solution are:

• Azure Cosmos DB - A NoSQL database for storing data.
• RabbitMQ - A reliable and mature messaging and streaming broker.

Notable packages used in this solution are:

• MassTransit - A framework that provides a abstraction on top of message transports, ie. in this example RabbitMQ. It can also be used with Azure Service Bus and Amazon SQS.
• FastEndpoints - A developer friendly alternative to Minimal APIs & MVC.