Processing Messages

This section covers how to process messages in Talon microservices - the core of your application's business logic. All business logic in a Talon microservice is written in message handlers, which are methods that the AEP Engine invokes in response to inbound messages.

Overview

Message processing in Talon follows a straightforward, event-driven model:

Message Arrival: An inbound message arrives on a channel that your microservice has subscribed to
Duplicate Detection: The AEP Engine checks sequence numbers to detect and discard duplicates
Filtering: Optional message filters determine if the message should be processed
Handler Dispatch: The AEP Engine dispatches the message to the appropriate handler(s) based on message type
Business Logic Execution: Your handler executes, reading the message, updating the microservice store, and creating outbound messages
Transaction Commit: When the handler returns, the AEP Engine commits the transaction, establishing consensus and sending outbound messages
Message Acknowledgment: The inbound message is acknowledged, completing the cycle

This simple model provides powerful guarantees: atomicity of store updates and message sends, exactly-once processing semantics, and automatic high availability through consensus with cluster members.

The Message Processing Flow

Here's a visual representation of how messages flow through a Talon microservice:

Inbound Message → AEP Engine → Message Handler → Transaction Commit
                      ↓              ↓                    ↓
                  Dispatch       Business           Store Updates
                                  Logic            Outbound Messages
                                                    Consensus

Key Characteristics

Event-Driven Architecture: Your code never polls or explicitly reads from queues. Instead, you write handlers that are invoked automatically when messages arrive.

Single-Threaded Processing: Each microservice processes messages on a single dispatch thread, eliminating concurrency issues and maximizing CPU cache efficiency. This is a fundamental design principle that enables Talon's performance.

Automatic Transactions: Every handler execution is automatically wrapped in a transaction. Store changes, outbound messages, and inbound message acknowledgment are atomic - they all succeed or all fail together.

High Availability Built-In: Depending on your chosen consensus model (Event Sourcing or State Replication), the AEP Engine automatically replicates data to backup instances and establishes consensus before committing transactions.

What You'll Learn

This section covers the complete message processing lifecycle:

Handling Messages

Learn how to write message handlers - the methods where all your business logic executes. Topics include:

Writing your first handler
Accessing and updating the microservice store
Handler signatures and annotations
Common patterns for message processing
Programming fundamentals and rules you must follow
Advanced topics like zero-garbage programming and transaction control

Sending Messages

Learn how to create and send outbound messages from your handlers. Topics include:

Creating and sending messages
Message keys and topic resolution
Channel configuration
Unsolicited sends (messages not triggered by inbound messages)
Send stability tracking

Message Processing Models

Talon supports two consensus models that affect how message processing works:

Event Sourcing (recommended for most applications):

Your microservice store consists of your own POJOs
The AEP Engine replicates inbound messages to backup instances
Backups replay messages to rebuild store state
Provides the lowest latency and highest throughput
Business logic must be deterministic

State Replication:

Your microservice store uses ADM-generated classes
The AEP Engine replicates store changes to backup instances
Provides simpler programming model for certain use cases

For conceptual understanding of both models, see Consensus Models.

Best Practices

Keep Handlers Fast: Handlers should complete quickly (typically microseconds to milliseconds). Avoid blocking operations, long computations, or external I/O.

Design for Horizontal Scaling: Partition your data across multiple microservice instances using message keys. Each instance processes a subset of messages based on their keys.

Embrace Determinism: Especially with Event Sourcing, ensure your business logic produces the same results given the same inputs. Don't rely on system time, random numbers, or external state.

Use Transactions Wisely: For most cases, rely on automatic transaction management. Use transaction controls only when you have specific requirements like incremental commits for large batches.

Getting Started

If you're new to Talon message processing, we recommend reading in this order:

Handling Messages - Programming Fundamentals - Essential rules you must understand
Handling Messages - How to write your first handler
Sending Messages - How to send outbound messages