Designing A Cloud Native Transaction Service with Azure Service Bus

Introduction

In my previous article on choosing the right Azure messaging service for your application, we discussed several constraints considerations needed when choosing the right messaging service. We move a step further to perform the actual determination for a banking application; the best messaging service and architecture for your application.

The application needs to perform a transaction where User A sends funds to User B. Upon receiving the funds, they should both receive transaction notifications detailing debit and credit transactions respectively. This message notifies each user of the amount of funds sent, their account balance and includes a transaction ID and timestamp for tracking purposes.

Business & Product Definitions

I have developed some user stories and acceptance criteria from a business and product perspective detailing what the business needs are (see here). We will use the features, user stories and acceptance criteria defined to develop an architectural perspective for the service. In the succeeding article, I will then develop backend APIs in Java/Spring boot and Azure to show how we put all pieces (business, product, architecture) together into a working solution.

Defining the Constraints

• Message Type : Our payment service uses a simple text-based notification message sent to User A and User B (e.g., "You sent $X to Y. Your new balance is $Z." or "You received $X from Y. Your new balance is $Z.").

• Message Size : A typical transaction message will have an average size of 1KB.

• Operations Per Transaction : We have 2 operations per transaction (1 send operation and 1 receive operation) for a pair of users.

• Receiver and Sender : 2 users (1 sender, 1 receiver) per transaction.

• Frequency : When a user needs to send funds to another user.

Analysis for Suitability of Azure Messaging for the Transaction Service

Given the application's requirements for reliable, transactional messaging and asynchronous notifications, Azure Service Bus is the most suitable choice (see detailed design considerations).

1. Azure Service Bus

Azure Service bus operates as an enterprise messaging as a service, designed for reliable, asynchronous message delivery, often used for decoupling applications, load levelling, and transactional messaging supporting queues (one-to-one) and topics (publish-subscribe).

Strengths relating to payment notification processing use case:

• Reliable Messaging: Guarantees "at-least-once" delivery, with features like Peek-Lock, Dead-Letter Queues, and automatic retries which are critical for financial transactions where messages cannot be lost.

• Transactional Support: ASB Can integrate with distributed transactions (e.g., Spring's @Transactional) ensuring messages are sent only if the database transaction commits.

• Message Ordering: Guarantees FIFO (First-In, First-Out) ordering for messages within a session which is important for sequential processing of related financial events.

• Message Sessions: Allows grouping related messages, ensuring they are processed together and in order by a single consumer.

• Complex Routing: Topics with subscriptions and filters allow for flexible message routing to different consumers.

• Managed Service: High availability, disaster recovery, scaling, and security are handled by Azure, significantly reducing operational overhead.

• Security: Built-in integration with Azure Active Directory, SAS tokens, and network isolation.

Azure Service Bus, however, has its weaknesses:

• Lower throughput compared to Event Hubs for massive streaming data.

• More expensive per message for very high volumes of simple events compared to Event Grid.

Thus, the typical case would be in order processing, financial transactions, workflow automation and decoupled micro-services which meet the needs of our payment service.

2. Azure Event Hub

Azure Event Hub operates as a big data streaming platform, designed for high-throughput, low-latency ingestion of millions of events per second from diverse sources and optimized for event streaming and analytics.

Strengths:

• Massive Scale & Throughput: Azure Event Hub is ideal for capturing telemetry, logs, clickstreams, and other high-volume data streams.

• Low Latency Ingestion: It is optimized for quick data capture like in IoT systems.

• Partitioning: It allows parallel processing of event streams.

Weaknesses:

• No Message Ordering Guarantee across partitions: Ordering is only guaranteed within a single partition.

• No Transactional Support: Not designed for atomic, transactional messaging.

• No Dead-Lettering (natively): Requires custom implementation for handling failed messages.

• Consumer Responsibility: Consumers are responsible for managing their own checkpoints and offsets.

Compared to Azure Service Bus, Azure Event Hub would not be suitable for our payment service notification processing. While notifications are "events," the reliability and ordering guarantees of Service Bus are paramount for financial notifications. Event Hubs is for streaming data for analytics, not reliable, individual message delivery for critical business processes. We need to ensure every notification is delivered, not just processed as part of a stream.

3. Azure Event Grid

Azure Event Grid operates as an event routing service, designed for reactive programming, allowing applications to react to events from various Azure services and custom sources in real-time.

Strengths

• Event-Driven Architecture: Excellent for reacting to state changes (e.g., new file uploaded to Blob Storage, new resource created in Azure).

• Fan-out Capabilities: Efficiently delivers events to multiple subscribers.

• Pay-per-event Pricing: Very cost-effective for low-volume, high-burst events.

• Serverless Integration: Integrates seamlessly with Azure Functions, Logic Apps, etc.

Weaknesses of Azure Event grid as relates to our notification processing needs :

• No Message Queuing: Not a message broker; events are pushed to subscribers, not pulled from a queue. No built-in retry mechanisms or dead-lettering for failed deliveries.

• No Message Ordering Guarantees: Events are delivered with best-effort ordering.

• No Transactional Support.

Azure Event Grid is not a suitable service for our use case as it is best designed for event routing (e.g., "a transaction happened, notify Service A, Service B, Service C etc."). It's not a reliable message queue for ensuring individual notifications are processed. Our requirement is for guaranteed delivery of notifications.

Conclusion: Why Azure Service Bus is the Optimal Choice

For a banking application primarily focused on reliable, transactional messaging for fund transfer notifications, Azure Service Bus is the superior choice due to:

1. Guaranteed Delivery & Reliability Features: Azure Service Bus provides Dead-Letter Queues (DLQ), Peek-Lock, and automatic retries are crucial for financial notifications.

2. Transactional Messaging: Its ability to integrate with distributed transactions ensures that a notification is only sent if the financial transaction successfully commits. This is a non-negotiable requirement for financial integrity.

3. Message Ordering (Sessions): Important if related notifications (e.g., multiple notifications for a single complex transfer) need to be processed in a specific sequence.

4. Reduced Operational Overhead: As a fully managed PaaS (Platform as a Service) offering, Azure handles scaling, patching, high availability, and disaster recovery, freeing up engineering resources to focus on core business logic.

5. Native Azure Integration: Seamless integration with other Azure services (like Spring Cloud Azure) simplifies development and deployment.

Coming up…

In the next article, we review the backend api design, and development of this solution. You can find the code here.

Activity Diagram

Happy architecting 😊.