These improvements are part of our ongoing path toward Infinitic v1.0 — making it easier than ever to build robust, distributed, event-driven systems.

⚙️ More Control Over Deployment Options

With v0.18.1, Infinitic now offers finer-grained control over how workflows and services are deployed. Whether you're scaling individual components independently or tailoring deployments for different environments (e.g., staging, production, multi-tenant systems), these new options make configuration both cleaner and more explicit.

Workflow State Worker Deployment

An Infinitic Workflow State Worker includes four components:

• workflowStateEngine

• workflowTimerHandler

• workflowEventHandler

• workflowCommandHandler

Before 0.18.1, all four components were deployed together, sharing the same concurrency parameter.

Now, you can optionally set specific concurrency values for:

• timerHandlerConcurrency

• eventHandlerConcurrency

• commandHandlerConcurrency

If you don’t specify them, they will default to the general concurrency value, preserving backward compatibility.

Executor (Service or Workflow) Worker Deployment

An Infinitic Executor Worker (used for services or workflows) includes three components:

• executor

• eventHandler

• retryHandler

Just like for workflow workers, you can now configure:

• eventHandlerConcurrency

• retryHandlerConcurrency

These also default to the general concurrency value if not explicitly set.

⏱️ Cooperative Canceling for Long-Running Tasks

In Infinitic, when a task exceeds its timeout, it is retried, but the current execution is not forcibly stopped. Instead, the task implementation is expected to detect cancellation cooperatively and exit gracefully.

This design is intentional — and critical for safe, resilient systems.

Forced Termination Is Unsafe

Forcefully killing a task (e.g., interrupting a thread) can lead to:

• Corrupted application state

• Leaked resources (e.g., locks, DB connections, files)

• Partial updates or unintended side effects

In distributed systems, where consistency and clean-up matter, abrupt termination is a recipe for trouble.

Graceful Cancellation Enables Cleanup

Letting a task continue running after a timeout gives it the chance to:

• Detect that it has been canceled

• Abort work cleanly

• Release external resources

• Report useful logs or metrics

This is the foundation of cooperative canceling, introduced in v0.18.1. Infinitic now provides a mechanism for task implementations to check for a cancellation signal and respond accordingly.

👉 Learn how to implement cooperative canceling →

Safe Retrying with Idempotency

When a timeout occurs, a new task attempt is scheduled. This retry mechanism assumes your tasks are either:

• Idempotent (safe to retry without harmful effects), or

• Compensated (with a mechanism to roll back or handle duplicates)

🔭 Looking Ahead

We’re actively working toward Infinitic v1.0.

If you're moving away from centralized orchestrators — or designing distributed logic from scratch — now is the perfect time to explore what Infinitic can offer.

📦 Upgrade Now

Update your dependencies to v0.18.1 and start benefiting from the latest features today:

implementation("io.infinitic:infinitic-client:0.18.1")
implementation("io.infinitic:infinitic-worker:0.18.1")

• 📘 Documentation

• 🧑‍💻 GitHub Repository

💬 Need Help?

If you’re evaluating Infinitic for production use, I’d love to hear about your specific requirements. Reach out directly at gilles@infinitic.io for:

• Architecture consultation

• Custom integration discussions

• Performance benchmarking assistance

• Roadmap input and prioritization

• Infinitic 0.18.0 fixes Pulsar critical message ordering issues that could cause unexpected workflow behavior

• We implemented transient storage for out-of-order messages and an optimistic locking pattern

• These fixes ensure reliable workflow orchestration even during workers rebalancing events

• Required action: Database migration needed to add a version column for optimistic locking

  ---

As we release Infinitic 0.18.0 today, I wanted to share some insights into a fundamental challenge we tackled in this version. If you've been using our workflow orchestration framework, this update will significantly improve reliability, especially when scaling up or down your workers.

The Critical Role of Key-Ordering in Orchestration

When I first designed Infinitic, one of my core principles was building a rock-solid foundation for workflow orchestration. At the heart of any reliable orchestration system lies a seemingly simple but absolutely critical requirement: key-ordering guarantee.

What exactly is key-ordering and why is it so essential?

In distributed systems like Infinitic, messages are constantly flowing between components. When these messages relate to the same workflow instance (identified by a unique key), the ordering of those messages can mean the difference between correct execution and subtle, dangerous race conditions.

Imagine a workflow that's waiting for two task completions before proceeding to the next step. If both tasks complete at nearly the same time and send their completion messages back to the workflow engine:

1. Task A completes and sends a completion message

2. Task B completes and sends a completion message

3. The workflow should process these in order to correctly update its state

Without key-ordering guarantees, the workflow might process Task B's completion first, then Task A's, potentially leading to incorrect state transitions, especially if the workflow logic depends on the specific order of completion or if the state update is done at the same exact moment.

This example illustrates why key-ordering isn't just a nice-to-have feature—it's fundamental to predictable workflow behavior. Without it, workflows become non-deterministic, making debugging nearly impossible and reducing reliability to unacceptable levels.

Apache Pulsar and the Key-Ordering Challenge

Infinitic has been built on Apache Pulsar since day one. We chose Pulsar for its modern architecture, scalability, and—crucially—its promised key-ordering guarantee.

In theory, Pulsar should ensure that all messages with the same key are delivered in the order they were published. However, as our users pushed Infinitic, we discovered edge cases where Pulsar's key-ordering guarantees weren't as robust as we expected.

The specific issue occurred during certain scaling scenarios. When Pulsar rebalances consumers (which happens during scaling events or after failures of a worker), there's actually a small window where messages with the same key could be processed out of order if they were assigned to different consumers.

For most messaging applications, this brief reordering might be acceptable. But for a workflow orchestration engine like Infinitic, even rare ordering violations can lead to incorrect workflow states and unpredictable behavior.

The Fix in Infinitic 0.18.0

Here's how we approached the problem:

1. Transient storage for out-of-order messages: We've implemented a system that detects when messages arrive out of sequence and temporarily stores them in a dedicated buffer. This ensures that even if Pulsar delivers messages in the wrong order, Infinitic can reorder them correctly before processing. When the expected preceding messages finally arrive, we can retrieve the buffered messages and process them in the correct sequence.

2. Optimistic locking pattern for state storage: We've introduced an optimistic locking mechanism when storing workflow state. Here's how it works:

   • When retrieving a workflow state, we also fetch its current version number

   • Before saving any updates to that state, we verify the version hasn't changed

   • If another process has updated the state in the meantime (detected by a version mismatch), we abort the current update, re-fetch the latest state, and retry the operation

   This approach prevents multiple workers from overwriting each other's changes and maintains state consistency even when processing concurrent messages.

These changes work together to create a significantly more robust orchestration engine that maintains strict key-ordering guarantees even under heavy load, consumer failures, or scaling events.

What This Means for Infinitic Users

If you're upgrading to Infinitic 0.18.0, you'll experience improved overall reliability for mission-critical workflows

Important upgrade note: This release requires a database migration to add a version column to your workflow state tables. This version column is essential for the new optimistic locking mechanism. We've provided migration scripts for all supported databases in our documentation, and the migration process is straightforward. Be sure to run these migrations before deploying the new version to production environments.

Looking Forward

Key-ordering isn't a flashy feature, but it's fundamental to the correctness guarantees that make Infinitic valuable for critical business workflows.

The solutions we've implemented not only fix the immediate issues but strengthen Infinitic's architecture for future scalability.

As always, we welcome your feedback on this release. The real-world scenarios you bring to Infinitic continue to push us to build a better product.

UPGRADE NOW

A big thank you to Yvonne from Infinitic and Matthieu from Splio for collaborating on this fantastic milestone.

TL;DR:

Splio’s Challenge
Splio, a SaaS marketing platform for retail and e-commerce brands, faced a critical challenge in 2020. Their existing campaign management system couldn’t keep up with modern demands for real-time, event-driven functionality. Scaling to handle millions of workflows daily required a significant overhaul. Their pain points included:

• Legacy infrastructure: Relied on database polling, which was resource-intensive and unsuitable for real-time responsiveness.

• Brittle custom code: Difficult to maintain, hindering innovation and draining engineering resources.

Why They Chose Infinitic
Infinitic provided a solution that enabled Splio to modernize their system without the burden of building and maintaining complex backend tooling. Key benefits included:

• Event-driven architecture: Transitioned seamlessly without adding technical debt.

• Time to Production: state management, error handling, and queuing were all ready to use, freeing engineers to focus on delivering features.

• Simplified codebase: Decoupled business logic from infrastructure, dramatically reducing complexity and improving maintainability.

The Impact
The results of adopting Infinitic were transformative:

• Faster Time-to-Market: The first version of their new campaign manager was delivered in just six months—saving 12 months of development, testing, and iteration.

• Rapid Feature Development: Over 20 new features were released in mere months, compared to years on their old system.

• Massive Scalability: Handled over 3 billion workflows with minimal incidents, supporting more than 600 clients.

• Increased Agility: Reduced feature development cycles to just two weeks, enabling faster iteration and user-driven updates.

Why the Splio Engineering Team Loves Infinitic

• Clean, maintainable code: Simplified, focused code requires less upkeep, leaving more time for innovation.

• Seamless testing and versioning: New features integrate smoothly without disrupting live campaigns.

• Infrastructure handled for them: Infinitic takes care of the "plumbing," so engineers can focus on business logic and delivering customer value.

With Infinitic, Splio has revolutionized its ability to deliver value to customers, all while keeping its engineering team lean, agile, and effective.

Check out the full story here: Splio Case Study.

Infinitic allows you to launch workflows using its client. These workflows can be triggered by various sources, including webhooks, application servers, and events processed by message brokers like Kafka or RabbitMQ. Whether you’re managing order events or integrating with existing APIs, Infinitic provides the tools to make the transition seamless.

Using Existing Events To Start Workflows

Imagine you’re handling order fulfillment and want to manage its lifecycle through existing events like OrderStartedEvent and OrderUpdatedEvent already present in a Kafka topic. Infinitic enables you to start workflows based on these events. Here’s an example of an order fulfillment workflow interface:

You can set up a Kafka consumer that listens for OrderStartedEvent and triggers a OrderFulfillmentWorkflow:

Pro Tip: Use tags like orderId:{orderId} to identify workflows. Tags make it easy to cancel workflows, or send signals later.

Sending Existing Events To Running Workflows

Infinitic also supports dynamic interaction with running workflows. You can trigger new methods in parallel or use channels.

For example, you can extend the Kafka consumer to forward some OrderUpdatedEvent and OrderDeliveryEvent events to their respective running workflows:

Leveraging Existing API-Based Services

Also, Integrating Infinitic doesn’t mean abandoning your existing API services. On the contrary, Infinitic allows you to reuse these services, offering:

• Automatic Retries: Handle failures seamlessly.

• Batch Processing: Improve efficiency.

• Timeout and Error Handling: Ensure robust operations.

Here’s an example of integrating a payment API:

1. Define the service interface:

2. Implement the service with an HTTP client:

3. Incorporate it into your workflow:

Why Infinitic?

By adopting Infinitic, you gain:

• Seamless Integration: Work with your existing systems without disruption.

• Flexibility: Harness the full power of loops, conditions, and data manipulation to define durable processes.

• Easy Maintenance: Workflows are easy to understand, consolidated in a single class, and version-controlled like standard code.

• Enhanced Observability: Comprehensive monitoring with detailed insights available on dashboards.

• Unmatched Reliability: Workflows remain resilient to service or worker failures, ensuring consistent operation.

• High Scalability: Infinitic's core event-driven architecture guarantees exceptional scalability.

With Infinitic, you’re not just adopting a tool—you’re future-proofing your infrastructure.

Ready to get started? Visit Infinitic Documentation for more details.

By reducing the frequency of network calls and database operations, batching enhances the performance of both Infinitic's internal processes (e.g., database updates) and user-defined tasks (e.g., bulk API calls).

How Batch Processing Works in Infinitic

Message Consumption

Infinitic components can consume multiple messages in a single batch from the message broker. This reduces the number of network calls required to retrieve messages.

For instance, instead of making 1,000 individual network calls to consume 1,000 messages, Infinitic retrieves them all in one call, minimizing latency and network overhead, particularly in high-volume environments.

Message Processing

Once consumed, messages are processed in batches, optimizing performance across two areas:

• Internal Components: Infinitic's internal engines, such as the Workflow State Engine and Service Tag Engine, consolidate multiple database operations into a single transaction.

• User-defined Tasks: Tasks are grouped and processed together, enabling efficient bulk operations, such as executing a batch of API calls.

Batching also applies to message sending, reducing the number of network calls required for publishing messages. For example, instead of sending 1,000 messages one at a time, a single network call can send them all.

Message Acknowledgment

Similarly, message acknowledgments (or negative acknowledgments) are batched. Rather than sending an acknowledgment for each message, Infinitic groups and sends acknowledgments collectively, further reducing network traffic.

For example, successfully processing 1,000 messages requires just one batch acknowledgment instead of 1,000 individual ones.

Executors: Comparing Processing Modes

Without batching

Messages are processed individually and in parallel based on the concurrency setting. Each message goes through three sequential phases:

1. Deserialization - The message is deserialized from its transport format

2. Processing - The actual logic is executed

3. Acknowledgment - The message broker is notified of successful processing

These phases happen independently for each message, as shown in the diagram below:

With batching

Messages are processed in batches and in parallel. Messages are received into batches based on the batch.maxMessages setting (e.g. 1000 messages per batch).

These batches are then processed in parallel according to the concurrency setting (e.g. 10 concurrent batches).

For example, with concurrency = 10 and batch.maxMessages = 1000, the system can process up to 10,000 messages simultaneously in memory

For Service Executors specifically, messages within each batch can be further re-grouped using a custom batchKey. This allows related messages to be processed together efficiently, as shown in the diagram below:

Workflow State and Tag Engines: Special Considerations

The Workflow State and Tag Engines require special handling to maintain data consistency:

• The Workflow State Engine must process messages for a given workflow instance sequentially to maintain workflow state integrity. For example, if workflow A has two pending messages, they must be processed one after another, not simultaneously.

• Similarly, the Workflow Tag Engine must process messages for a given workflow tag sequentially, to avoid race conditions.

Without batching

Messages are first sharded by their key (workflow ID for State Engine, workflow tag for Tag Engine) to ensure sequential processing within each key. Then messages are processed individually and in parallel based on the concurrency setting, but messages with the same key are never processed simultaneously. This is illustrated in the diagram below:

With batching

Messages are first collected into batches based on the batch.maxMessages setting (e.g. 1000 messages per batch). These batches are then sharded by their key (workflow ID for State Engine, workflow tag for Tag Engine) to group related messages together. The resulting key-based batches are processed in parallel according to the concurrency setting, while ensuring sequential processing within each key.

This approach optimizes throughput while maintaining data consistency by:

• Processing multiple independent keys in parallel

• Batching related messages with the same key together

• Preserving sequential processing order within each key

• Minimizing database transactions through batch processing (only one read and one write by batch)

Real-World Performance Gains

While Infinitic hasn’t yet undergone third-party benchmarking, internal testing highlights its potential:

• Local Testing: Up to 10x throughput improvement with batching enabled.

• Scale Benefits: More pronounced at larger scales, especially under high-concurrency workloads.

In one test, Infinitic processed 100,000 simple workflows (2 tasks each) in just 1 minute with only 2 workers on a single MacBook.

Get Started with Infinitic 0.16.2

The addition of batch processing underscores Infinitic’s commitment to delivering scalable, high-performance solutions. Whether you’re managing high-throughput systems or orchestrating complex workflows, this feature is a game-changer for efficiency.

Explore the official documentation to start integrating batch processing into your applications today!

Why Batch Processing Matters

Batch processing in Infinitic is ideal for scenarios such as:

• Bulk Database Operations: Minimize connection overhead with grouped inserts or updates. Instead of executing 1,000 individual inserts, perform them in batches of 100, reducing connection overhead by 99%.

• API costs: Efficiently manage external service requests within usage constraints. If you pay an API per request, Infinitic optimizes request batching to reduce costs while processing as many tasks as possible.

• Resource-Intensive Computations: Optimize CPU and memory use by consolidating tasks. Process multiple computations together, reducing system overhead and improving overall throughput.

  Subscribe for free to receive new posts and support our work.

How It Works

The new batch execution model lets developers define batch parameters using annotations like @Batch(maxMessages, maxSeconds), configuring tasks based on size and timing.

• maxMessages: Defines the maximum number of tasks that can be grouped into a single batch. Once this threshold is reached, the batch is immediately processed. Example: With maxMessages = 50, if your system receives 175 tasks:

  • First 50 tasks → Batch 1 (processed immediately)

  • Next 50 tasks → Batch 2 (processed immediately)

  • Next 50 tasks → Batch 3 (processed immediately)

  • Remaining 25 tasks → Wait for more tasks or maxSeconds timeout

• maxSeconds: Sets a maximum waiting period after receiving the first task in a batch. Ensures tasks don't wait indefinitely if the maxMessages threshold isn't met. Example: With maxSeconds = 1.0:

  • First task arrives at T+0

  • Only 24 more tasks arrive within 1 second

  • At T+1 second, all 25 tasks are processed together, even though maxMessages wasn't reached

Additionally, an optional batch key can be added to the task metadata. When present, the task will be added in a batch with other tasks having the same batch key.

Note: batches are counted as a single execution for the concurrency parameter, meaning up to concurrency batches may be processed in parallel.

Use Case Highlight

Consider a high-traffic service needing to process bulk email requests. With batch processing, you can set maxMessages = 50 and maxSeconds = 1.0 to efficiently send emails while adhering to API rate limits. Yet each email’s response remains distinct, allowing fine control over individual results in the workflow.

Let's examine a practical implementation:

@Batch(maxMessages = 50, maxSeconds = 1.0)
Map<String, EmailResult> sendEmail(Map<String, EmailRequest> requests) {
  // Batch process up to 50 emails or after 1 second
 return emailService.sendBatch(requests);
}

This simple configuration delivers impressive benefits:

• Reduces API calls by up to 98%

• Preserves workflow flexibility

Getting Started

To dive deeper into implementing batched tasks, explore our documentation. Try out this feature and share your experience with the community!

Subscribe now

If managing event-driven applications feels like untangling a web of interconnected services, you’re not alone. Many developers encounter chaos and technical debt as new services react to one another in unpredictable ways. The root cause? The widely adopted choreography pattern.

Why Choreography Leads to Chaos

The choreography pattern, where services directly consume and react to other services’ events, is technically efficient at runtime, when your system is in production. However, this operational efficiency comes at a cost as it is difficult to code, maintain, and scale. Let’s explore why:

• No Clear Ownership of Business Processes: In a choreography setup, business logic is dispersed across multiple services, making it challenging to assign ownership or even document the overall process.

• No Clear Path for Versioning Processes: When business processes are scattered across numerous event-driven services, rolling out updates or implementing changes without breaking running processes becomes a daunting task.

• Limited Service Decoupling: In the choreography pattern, services are tightly coupled by their reliance on consuming and reacting to each other’s events. This coupling increases the risk of making changes as you do not really know who is consuming your events.

• Security and Governance Concerns: In a choreography model, services may receive and process data that they don’t need, simply because it’s required further down the line. Without a single orchestrator to manage interactions, enforcing security policies and governance standards becomes complex and less reliable.

Why Choose the Orchestrator Pattern?

In contrast to the complexity of the choreography pattern, the orchestrator pattern provides a structured and centralized approach to managing business processes. Here’s why it stands out as a more effective solution:

• Clear Ownership of Business Processes: With an orchestrator, there’s a dedicated service that oversees and coordinates each workflow. This makes it easier to assign clear ownership and accountability, as well as document processes comprehensively.

• Streamlined Versioning and Change Management: The orchestrator acts as a single point of control, making versioning straightforward. Changes to business processes can be rolled out consistently and reliably.

• Enhanced Service Decoupling: The orchestrator pattern improves decoupling by reducing the direct dependencies between services. Services communicate via commands and events through the orchestrator, allowing them to focus on their specific tasks without needing to know the internal workings of other services.

• Enhanced Security and Governance: The orchestrator controls what data services receive, ensuring that services only access the information they need. This centralized oversight allows for more effective enforcement of security policies and governance standards.

Introducing Infinitic

Embracing the orchestrator pattern requires the right tools, and this is where Infinitic truly shines. Infinitic is designed to simplify the adoption of an orchestrated, event-driven architecture by automating much of the behind-the-scenes complexity.

Infinitic’s SDK manages essential components of event-driven systems, such as topic creation, schema management, serialization, and event definition. Developers only need to define business workflows and services; Infinitic takes care of communication between services by implementing message consumers and producers.

Infinitic also provides built-in error handling and resilience features, which keep workflows running smoothly even in the face of worker or service failures. This resilience gives developers confidence that their business processes are durable and reliable.

In essence, Infinitic removes much of the heavy lifting involved in adopting the orchestrator pattern. It allows developers to focus on their business logic while ensuring that infrastructure, scalability, and resilience are taken care of automatically. With Infinitic, you can build robust, scalable event-driven applications without sacrificing maintainability or simplicity.

Simplify and Strengthen Your Architecture

If you’re struggling with the pitfalls of the choreography pattern, it might be time to rethink your approach. Give Infinitic a try, even on an existing code base, and see how it simplifies the development of new features.

I’d love to hear your thoughts! Have you faced challenges with event-driven architectures? What has your experience been with orchestration versus choreography? Share your insights in the comments below or reach out directly!

Core Enhancements

• Added support for PostgreSQL for storing workflow states

• Developed configuration using builders instead of configuration files, enabling easier integration with frameworks like Spring

Documentation Expansion

We've made significant additions to our documentation website:

New Playbook Section

Our new Playbook section is born from real user questions about implementing specific use cases. It serves a dual purpose: demonstrating Infinitic's capabilities and providing practical guidance to our users. This section includes:

• Workflow Scheduler: Learn how to build a scheduler to execute workflows on a recurring basis. Remarkably, Infinitic achieves this without requiring additional infrastructure like cron jobs or dedicated database tables.

• Promises on Remote Tasks: Discover how to execute remote tasks asynchronously while still maintaining the ability to handle their errors or perform actions after task completion.

These examples not only showcase what Infinitic can do but also offer ready-to-use solutions for common scenarios our users face

Third-Party Pulsar Provider Guide

We've added a comprehensive guide on using Infinitic with external Pulsar providers, including:

• CleverCloud: A Europe-based Platform as a Service (PaaS) provider offering a managed Pulsar service with a focus on developer experience and scalability.

• Datastax: Known for their expertise in Apache Cassandra, DataStax offers Astra Streaming, a cloud-native messaging and event streaming platform built on Apache Pulsar.

• StreamNative: Founded by Pulsar's original creators, StreamNative provides a cloud platform for messaging and event streaming, with deep expertise in Pulsar technology.

Serialization Guide

A new section detailing Infinitic's updated approach (as of version 0.15.0) to data serialization has been added to help you understand how Infinitic uses and leverage serialization.

We encourage you to explore these new resources and provide feedback as we continue to evolve both Infinitic and its documentation. Your input is invaluable in shaping the future of our platform and ensuring our documentation meets your real-world needs.

We’ve been talking with a lot of teams lately to understand the friction points of implementing Infinitic and downstream benefits that teams realize after they are in production. So far we’ve learned:

Frictions:

• People are initially excited about Infinitic's potential, but often grapple with implementing its 'architectural pattern'. Infinitic eliminates the need to develop and maintain a variety of separate tools and systems: cron jobs, state management and continuous database polling, background workers, resilient API construction. Avoiding these disparate systems streamlines development, but the paradigm shift can be challenging to grasp at first.

• Additionally, two main hurdles currently exist for adoption: teams must manage Apache Pulsar, and applications need to be written in Java or Kotlin. These requirements can present significant barriers, despite the potential benefits of Infinitic's unified approach.

Benefits: once teams have figured it out and are using it, they rave about how quickly they built their use case and how they can quickly (and reliably) make updates with new versions. See our customer spotlight below to hear more! 👇

So we’re focused on communicating how Infinitic works (see our new website!) and offering development support plans to help companies with implementation. We’ve also made improvements to the documentation to help teams get from 0-1 with a managed version of Pulsar (and we’re considering some ideas to enable applications in other languages to run workflows).

Infinitic has a new website!

Our new website is intended to give a high level overview of how Infinitic can help Application teams build scalable event-driven processes, how it works and some use cases. Check out and let us know what you think.

Infinitic Support Plans

While we’ve always offered support for companies using Infinitic, we’ve recently formalized our offering and now offer 2 tiers of support starting at $2,000/month. We also offer Co-development services which can include extending the functionality of Infinitic or developing complementary modules specific to the company's needs. Just hit reply if you would like more details.

Company Spotlight

Splio has been using Infinitic for almost 3 years and is running millions of workflow instances per day. Their platform enables mid-market retailers to build workflows that send personalized communications to customers based on their behavior and signals.

When Splio first implemented Infinitic 3 years ago, it enabled them to build the backend infrastructure and logic for this important feature on their platform in a matter of weeks instead of months - without compromising scalability or reliability.

Using Infinitic has also allowed them to easily make tweaks to the logic based on product requirements AND offered their clients flexibility in the personalization and timing of communications. Anytime they make updates to the logic or UI, they appreciate being able to deploy a new version of their workflows without disrupting running workflow instances.

We Want To Hear From You!

Have questions or want to talk about some ways that your team can build better event-driven processes with Infinitic? Schedule a time to chat.

Connect with Infinitic:

Follow Infinitic on Linkedin

Star us on Github!

About Infinitic:

Infinitic is an open source orchestration framework for application teams to build durable and flexible event-driven workflows without managing the complexities of infrastructure or accumulating tech debt.

Workflows as Code: Replace distributed logic and fragmented execution across crons and API calls with centrally managed workflows that define the logic for each instance according to incoming data and events.

Orchestration Layer: Infinitic is the central ‘brain’ of your microservices and communicates through events to trigger ‘tasks’ in multiple services at the right time - and manage the state of each workflow instance.

Built-in Durability: The state of each step is automatically stored and no messages are never lost. Workflows are reliable and any issues can easily be traced in any workflow instance and resolved and restarted. Includes an API for end to end observability

Infinitic is an easiest way to build scalable and reliable even-driven applications, without having to deal with all the complexity.

Introducing CloudEvents (Beta)

One of the most significant additions in this release is the introduction of CloudEvents. Infinitic now exposes its events in the CloudEvents JSON format, allowing users to build their own dashboards, logs, or even add hooks to specific events. This feature opens up a world of possibilities for monitoring, auditing, and integrating Infinitic with other systems.

Some of the events exposed include:

• Workflow-related events, such as methodCanceled, methodCompleted, methodFailed, methodTimedOut

• Task-related events, such as taskDispatched, taskCompleted, taskFailed, taskTimedOut

• Child-workflow-related events, such as remoteMethodDispatched, remoteMethodCompleted, remoteMethodFailed, remoteMethodCanceled, remoteMethodTimedOut

Each event is accompanied by relevant data, such as error details or method arguments, providing valuable context for monitoring and troubleshooting.

This feature is currently in beta and may be refined based on user feedback.

Delegated Tasks

Infinitic 0.13.0 introduces the concept of "delegated tasks," addressing scenarios where tasks cannot be processed directly by a worker and instead require invoking an external system. Previously, if the external system could not provide a synchronous response, Infinitic would be left without a clear indication of the task's outcome or the ability to retrieve the result.

With the delegated task feature, enabled through an annotation on the task, Infinitic understands that the method's completion does not signify the task's completion and awaits asynchronous notification of the task's outcome. A new completeDelegatedTask method has been added to the Infinitic client to support this functionality.

Performance Improvements

Infinitic 0.13.0 brings several performance improvements to enhance the efficiency of your data operations:

Sortable UUIDs: Infinitic now uses UUID version 7, which includes a timestamp, expected to enhance performance when used as primary keys in databases.

Idempotency Keys: The taskId can now be reliably used as an idempotent key, as Infinitic will generate the same value for taskId even if the task creation process is duplicated.

Optimized Workflow Initiation: The topics architecture has been optimized, allowing the first task to be processed immediately upon dispatch, substantially reducing the "time to first execution" during surges in workflows launch.

Worker Graceful Shutdown: Workers now attempt to complete any ongoing executions before shutting down, with a configurable grace period, ensuring less duplicated messages during shutdown.

Quicker Worker Start: Upon startup, workers now verify and set up the necessary resources (tenant, namespace, topics) in parallel, significantly reducing startup time, especially in scenarios with a large number of tasks or workflows.

I’m thrilled to announce 0.12.1 a significant update to Infinitic, the scalable workflow engine that extends your event streaming cluster with durable execution capabilities.

🚀 New Feature: Global Timeout

In previous versions of Infinitic, you already had the option to implement a 'runtime timeout' for tasks. Essentially, if a task's execution time exceeded the predetermined limit, it would be flagged as a failure by the task worker. However, there were limitations, such as the inability of the worker to report timeouts in cases of crashes, memory shortages, or network issues. To address this, we're introducing a new 'global timeout' feature in this latest release. This feature designates a task or child-workflow as timed out at the workflow level if no result is provided within the set timeframe. This feature is useful to ensure that your workflow is not stuck even when workers experience malfunctions. Remember to consider the time spent in queues and potential retries when setting a global timeout.

🪲 Bug Fixes

In my pursuit of maintaining seamless backward compatibility, I conducted thorough tests on the new version and discovered a previously unnoticed bug. Since version 0.9.0, we've systematically ensured that new releases can interpret messages from all prior versions. However, an oversight occurred with a class serialized within a message, leading to potential workflow stalling during Infinitic upgrades. Although a simple retry could resolve this issue, it was still a bug. I'm pleased to report that this issue has been addressed and rigorously tested in the current release, ensuring smoother upgrades and system stability.

🔬 Improvements

This release brings several key under-the-hood enhancements:

• Pulsar resources are dynamically created as needed. In particular, your client does not create its own topic anymore if it does not need it

• Infinitic now validates worker configurations, checking that provided implementations actually implement the named tasks or workflows. This feature prevents the launch of misconfigured workers and saves you from potential confusion.

• Workers have been improved to notify the workflow engines about messages automatically sent to dead letter queues by Pulsar. Moreover, an automatic subscription to these queues has been added to ensure no message loss.

• A significant refactoring of Pulsar and inMemory implementations lays the groundwork for future compatibility with other data stream technologies like RabbitMQ and Kafka, broadening Infinitic's applicability.

Stay tuned for more updates as I continue to evolve Infinitic to meet your distributed workflow needs!

Gilles Barbier

It has been a while since I released an Infinitic newsletter. 6 months actually - you can not say I’m cluttering your mailbox! I should have been given news more often, but I’ve been pretty busy. Infinitic reached version 0.11.2 - here is what happened since 0.9.4:

Workflows state can be stored in MySQL

This is the first significant contribution coming from external contributors :) Until now, Redis was the only store proposed to store states of workflows; now you can use MySQL. To do so, just provide this configuration to your workers:

storage:
  mysql:
    host: 127.0.0.1
    port: 3306
    user: root
    password: 
    database: infinitic

Backward compatibility ensured

Infinitic now has tests to ensure that all versions have backward-compatible schemas since 0.9.0. This ensures that messages already in Pulsar - and binary states stored in databases - can be handled when you upgrade your Infinitic version.

As it’s a backward compatibility only, you can still have issues if you mix workers/clients of different versions or if you try to roll back Infinitic after an upgrade. I’m thinking of introducing a full-compatibility policy before the first stable release.

Timers can be manually completed

When using timers, please check that topics containing delayed messages have a TTL covering the duration of your timers. Per default, Infinitic now sets a one-year TTL in those topics (whose name contains “delay”). Make sure that your Pulsar cluster allows topic-level settings.

Be careful; if your timer’s duration is longer than the TTL, the timers won’t be fired. For those situations, Infinitic now proposes a `completeTimers` command to complete the running timers manually when needed.

Improved workers configuration

• Timeout and retry policies are now easier to configure at the worker level. Those policies can now be independent of services/tasks implementation.

• Services can also be manually registered to workers. This allows dependency injections if needed.

• Default settings for Pulsar’s consumers and producers can now be provided.

Workflow versioning

Infinitic now lets you version your workflows. Workflow versioning is a tricky subject, and I waited a bit on this one to make sure to provide the simplest API.

The easiest way to update a workflow today is to have the new instances use the latest version while the current instances continue to run the version they were started with. This is now possible with a simple configuration of workers.

What’s next for Infinitic?

I’d like to mention here a few things that I believe are worth discussing before reaching a stable 1.0 version.

Use of protobuf - RPC framework

At its core, Infinitic is also an RPC framework, allowing distributed executions of remote services. By pure ignorance, I did not consider the ongoing works in this area (e.g. gRPC), when developing the foundations of Infinitic. I believe today that Infinitic should evolve as a generic Pulsar-based RPC framework. One way to follow this direction is to start using Protobuf for declaring services and their input/output and to code an Infinitic protobuf plugin to generate stubs.

I’m also looking at other emerging initiatives such as CloudEvents and AsyncApi - but the benefits for Infinitic seem less obvious - but I’m curious to hear your thoughts about them.

State storage

Since its beginnings, I wanted Infinitic to be usable with only a Pulsar cluster running - without having to add any other pieces of infrastructure. This vision is not fulfilled yet, as we still must have databases to store states. This should be temporary as those states were supposed - eventually - to be managed by Pulsar stateful functions. But it’s not that clear anymore:

• stateful functions seem to have a hard time reaching a “production-ready” label

• stateful functions would not be suitable for multi-region Pulsar deployment

I wonder if Infinitic should follow an event-sourcing pattern instead of relying on storage. These are preliminary thoughts, and I’m curious to hear if you have opinions on how (and if) to do this.

Dashboarding

Infinitic already has a dashboard focused on monitoring its workers and topics. It would be great to extend it to be able to display the state of workflows. Initially, I was hoping not to have to add dedicated databases for requesting events. I believe I should now build connectors and interfaces to work with databases such as elastic or Postgres.

By the way, the excellent library Kweb I use to build dynamic UIs without javascript just reached the 1.0 version. I encourage you to test it.

Observability

This one is probably a quick win - integrating OpenTelemetry and/or Micrometer into Infinitic. Contributions are welcome ;)

You may have noticed or not, but I have been silent since October last year. So you may wonder if Infinitic is still alive. The response is Yes! Actually, Splio, the French marketing company I worked with last year, is now using it in production to power its new automation marketing engine. And today, I released version 0.9.4.

The reason behind my silence is that I have joined a US startup - StreamNative - as General Manager for the EMEA region! If you do not know StreamNative yet, its activity is to manage Pulsar clusters for its customers. The company was founded by the original creators of Apache Pulsar and has more experience deploying and running large-scale instances than any team in the world. My role there is to accelerate StreamNative’s growth in the EMEA region by building a local team to serve our customers and increase Pulsar awareness.

What does it mean for Infinitic?

StreamNative did not buy Infinitic and does not support it officially currently. So obviously, even if I enjoy working on it in my spare time, the development of Infinitic has naturally slowed down due to my new role. But even if I can’t be sure of the medium-term consequences, I still think that being so close to the Pulsar ecosystem should ultimately benefit Infinitic.

So, what’s new in this 0.9.4 version?

Channels are more versatile!

Before 0.9.4, it was impossible to buffer signals in a channel to handle them later. The closest you could do to buffer three signals was:

Since 0.9.4, Infinitic is now able to buffer signals to handle them by a workflow:

It’s even more helpful if you do not know the number of signals you will receive:

Using this pattern ensures that your previous signal is entirely handled before handling the next one. We can imagine multiple use cases:

• Send events relative to a user to a loyalty workflow

• Send events relative to a basket to a workflow managing baskets for an e-commerce website

Let me know your use case.

Unique tag

Let’s say you create a workflow describing a loyalty program. Despite having multiple triggers to start this workflow, you want to ensure that a user can not have more than one workflow running at a given time. Before 0.9.4, the only solution was to tag the workflow with “userId:b4824916” then request the existing ids associated with this tag to check if we have already a running workflow before starting a new one:

This method is cumbersome and sensitive to race conditions. Since 0.9.4, you can do:

By prefixing a tag with “customId:” we tell Infinitic that this tag is a custom id for this workflow. When dispatching it, Infinitic will check if a workflow (of the same type) with the same tag already exists before starting a new one.

I hope you will find those new features useful. Let me know what you think by responding to this email ❤️

I'm excited to announce this 0.8.0 release because it's an important step towards the completion of the vision behind Infinitic. With this release, we are now able to run multiple methods in parallel for the same workflow instance, as described in the new parallelization and properties pages of the documentation:

Why it's a big deal?

Easy interactions with running workflows

First, it provides an easy way to interact with a running workflow. For example, the code below is all you need to build a simple loyalty system that is scalable, stateful, long-running, and failure-tolerant:

Note how easily the `start` method describes a loyalty program where the user earns one point per week.

Now the `addBonus` method lets us easily add bonus points based on specific events:

Easy access to properties of running workflows

Second, this new feature provides an easy way to know the internal properties of a workflow just by synchronously running a getter from an Infinitic client:

By removing all the complexity and letting developers focus on the business logic, Infinitic introduces a new paradigm for building failure-proof scalable systems. This example only scratches the surface of what is possible.

Let me know what you think, by responding to this email ❤️

I’m pleased to announce that release 0.7.1 of Infinitic, which includes the first version of the Infinitic Dashboard, is now live!

This first release focuses on providing you an easy way to monitor your infrastructure, showing statistics for Pulsar topics used specifically to manage each task/service or workflow.

List of workflows and tasks

Once set up with a Pulsar URL, tenant, and namespace, the dashboard presents all tasks and workflows that have been processed through your cluster:

You can see at a glance the # of deployed executors and their total backlog and throughput for each of them.

Note: for a near-real-time execution, you should have enough executors to prevent the backlog from growing.

Detail of topics used to run the workflows

For each workflow name, a set of topics are automatically deployed on Pulsar:

By clicking on a workflow name on the dashboard, you can see the real-time statistics of all of them:

Detail of topics used to process the tasks

For each task name, a set of topics are automatically deployed on Pulsar:

By clicking on a task name on the dashboard, you can see the real-time statistics of all of them:

Stats for a topic

Note that for each topic, you can see the very detail of its  metric by clicking on it:

Next Steps

The complete observability of the processings of tasks and workflows is an important part of the vision behind Infinitic. So for the next iteration of the dashboard, I will focus on showing the details of the processing of an instance of task/workflow. 

Notes

It would not have been possible to write such polished UI without those 2 fantastic pieces of software:

• tailwindUI: a collection of ready-to-use polished UI responsive components written with the tailwind CSS framework

• KWeb: a Kotlin framework that lets you write a reactive interface without writing a single line of javascript (for me, the future of web development!)

I encourage you to have a look at them!

Please answer directly to this email for any feedback; it means a lot to me :)

It has been a while since my last email, but a lot happened meanwhile:

• Infinitic v0.6.0 is out with simplified deployment and improved error management.

• Infinitic has had its first formal load testing during the last Pulsar Hackathon.

• Infinitic will be at the next Pulsar Summit North America!

Simplified deployment

You may remember that Infinitic is based on engines (workflow engines, task engines, tag engines…) you need to deploy along with some workers actually processing tasks and workflows. Well, since Infinitic v0.6, the deployment is greatly simplified with only task workers and workflow workers.

Since v0.6, the task and workflow engines are embedded per default into task workers and workflow workers. And each task and workflow have their own engine instances. The first motivation to do that was to optimize the flow of messages into Pulsar: a large afflux of messages for a specific workflow should not delay another workflow. 

Incidentally, it provided the opportunity to simplify the deployment by embedding everything a task/workflow needed into a task/workflow worker. The Pulsar topics architecture is still the same: 

But now, a lot of this complexity is internal to workers.

Error management 

Up to now, a task could not fail in a workflow. Of course, a task could fail, but Infinitic would automatically retry it to its completion and the workflow's resume. It implied that a workflow could be stuck forever if a task failed unrecoverably. 

I recognize that there are situations where workflow needs to continue even if a task could not complete. So, from v0.6, you can catch the task failure directly within the workflow code to react to this situation. It is quite a sophisticated piece of code; also, I recommend you look at the documentation.

A pleasant consequence of this new feature is that a workflow now raises an exception when stalled due to a task failure. And this exception recursively contains the reason for the chain of failures. It means you can easily find the root cause of the issue (that could be a failed task in a child workflow, for example). Debugging an event-driven architecture is notoriously tricky, and this new feature will tell you where exactly the root failure occurred in your distributed infrastructure.

Load testing Infinitic during the last Pulsar Hackaton

With Matthieu Jacquet (from marketing company Splio) and John Kinson, we have participated in the last Pulsar hackathon. We decided to build the prototype of a bench to load-test Infinitic. During this 48h hackathon:

• We have written a workflow launcher to be able to dispatch workflows according to a scenario defined in a configuration file;

• We have written a workflow, emulating the request of 2 different providers for a product,  followed by an order ordering to the quickest one responding positively;

• We have set up a local Docker configuration to run Prometheus and Grafana to get nice dashboards;

• We were able to run all developments above on a hosted Pulsar provided by CloudNative;

• We did a nice 10' min video of this work that I hope to release soon.

I'm thrilled with the results, as we were able to reach consistently a completion rate of 20 workflows/second (nearly 2 million workflows per day) with a unique worker (basic Macbook Pro) and a minimal Pulsar cluster.

Workflow engines often have a bad reputation for being slow and a single point of failure. Event-driven workflow engines like Infinitic are pushing those limits. I really believe that this technology will be more and more common in the coming years.

Pulsar Summit

Last but not least, I'm thrilled to share that my paper "Infinitic: Building a Workflow Engine on Top of Pulsar" has been accepted for the next Pulsar Summit:

This is a great event for anyone interested in messaging and event streaming to learn the latest Pulsar project updates, use cases, and best practices! I can’t recommend enough you to join :)

That’s it for today. Be safe.

I’m happy to announce the 0.5.0 release of Infinitic with an important new feature: tags!

You can now label workflow instances with tags. And apply commands, such as sending events, or canceling, to all workflows marked with a tag. 

By using tags, Infinitic avoids you maintaining mapping tables between Infinitic Ids and your own ids.

Let's take an example continuing the example in my last email: how to plug Infinitic into an existing event stream (from Kafka, for example):

To do so, you will need a dispatcher between your current event stream and Infinitic. This dispatcher should: 

• trigger workflows based on events type and values

• forward events to existing workflows.

A requirement to keep the code simple is to have this dispatcher as dumb as possible. This release 0.5.0 (and the previous 0.4.3) brings an elegant solution to this problem.

Most of the time, your events have a primary id describing your resources. Depending on your activity, it could be a UserId, an OrderId…. When starting a new workflow, you can label it with a tag containing this id, such as

"userId:d15376a4-600b-483b-9eeb-373209361557"

By introspecting the type of channels for each workflow interface, the dispatcher knows which type of workflows waits for which event. When receiving a new event, the dispatcher can forward it to the relevant workflows having the right tag. The workflow engine will automatically discard the event if not waited and will process it otherwise.

I hope you start to see how tags can greatly simplify your implementations. 

This 0.5.0 release contains even more goodies: have a look!

As always,  I need your feedback, question, or reaction ❤️.