Skip to content

Conversation

@indriesergiu
Copy link

@indriesergiu indriesergiu commented May 23, 2025

This PR aims to increase the throughput of the transactional outbox by implementing batch processing for ordered items.
This significantly improves performance while maintaining ordering guarantees within topics.

Details

  • Ordered Batch Processing: Process items in batches while maintaining order within topics
  • Parallel Execution: Run different topic batches in parallel
  • Efficient Locking: Batch locking of entries to improve performance
  • Error Handling: Comprehensive error handling for batch failures
  • Listener Notifications: Properly notify listeners of success/failure events
  • Testing: Dedicated tests to verify functionality

Batch Error Handling

The implementation uses an all-or-nothing approach for error handling in batch processing. When any entry in a batch fails during execution, the entire batch is marked for retry, maintaining strict ordering guarantees within topics. This approach ensures transactional consistency at the cost of potentially reduced throughput when problematic entries exist. Upon failure, the system increments attempt counts for all entries in the batch, triggers appropriate failure listeners, and rolls back the transaction. This guarantees that entries within a topic are always processed in sequence, even after failures. The batch will be retried according to the configured retry schedule until successful completion or until entries reach their maximum attempt threshold and become blocked. This simpler approach prioritizes correctness and ordering over partial processing, making the system more predictable when handling failures.

Important Notes

  1. I've temporarily disabled 2 tests for (MS SQL and MySQL) since they're not a priority for us, but this can be solved moving forward
  2. See details regarding the batch error handling above. The implemented behavior is a simple solution that matches our needs, but we can discuss changes.
  3. I avoided adding a batch method to the Submitter interface and worked around that by using the same Executor. I assume we will have to change this in some way.

Looking forward to feedback :)

@badgerwithagun
Copy link
Member

Thank you @indriesergiu! This needs some thought. I'll get back to you

@indriesergiu
Copy link
Author

Cool, thanks!
Waiting to hear from you :)

@badgerwithagun
Copy link
Member

HI @indriesergiu . Apologies for the delay in reviewing. I'll try and get around to it this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants