Celigo Topics: Native publish/subscribe without a separate broker
Modern integration architectures need to do more than move data from one system to another. A single business event, such as a new order, an updated customer, a completed shipment, or a changed employee record, may need to trigger several independent processes.
- Fulfillment may need the event to ship an order.
- Finance may need it for billing.
- Analytics may need it for reporting.
- An AI-assisted workflow may need the same event to evaluate risk or initiate the next action.
Point-to-point integration was not designed for that kind of fan-out.
When a producer is wired directly to each consumer, every new downstream process adds more dependency. Adding a new consumer can require changes to the producer. Pausing one consumer can complicate the rest of the process. The architecture gets harder to change as more teams need the same event.
Celigo Topics brings native publish/subscribe messaging into Celigo, so producers can publish an event once and multiple flows can consume it independently.
A quick look into Celigo Topics
Why point-to-point integration breaks down as event demand grows
Point-to-point integrations work well when one system needs to send data to one destination.
But many business events need to be reused.
An OrderCreated event might need to:
- Start fulfillment
- Create billing context
- Update a reporting dataset
- Notify a sales or support team
- Trigger an exception review
- Feed an AI-assisted decision workflow
In a tightly coupled design, each new consumer adds more wiring. The producer needs to know who should receive the event, how to send it, and what happens if one downstream process is unavailable.
That creates more work for integration teams and more fragility in the architecture.
Publish/subscribe messaging changes the pattern.
Instead of sending directly to each consumer, the producer publishes the event to a topic. Subscriber flows consume from that topic independently.
Producer → Topic → Subscriber A
Producer → Topic → Subscriber B
Producer → Topic → Subscriber C
The producer does not need to know how many subscribers exist. New subscribers can be added without redesigning the producer. One subscriber can pause or fail without stopping the others.
What is publish/subscribe messaging in an integration platform?
Publish/subscribe messaging, often called pub/sub, is an integration pattern in which producers publish messages to a topic, and subscribers consume them.
- A producer creates the message.
- A topic receives and retains the message for a configured period.
- A subscriber consumes messages from the topic independently.
This model is useful when the same event needs to power multiple automations.
For integration teams, the value is simple: publish once, subscribe many times.
Connecting to a message broker vs. operating one natively
There is an important difference between connecting to an external message broker and operating the broker inside the integration platform. The platform itself has to receive published events and distribute them to consumers to genuinely provide message/event brokering, not just talk to one.
In the connector model, the broker exists somewhere else:
Producer → external broker → Celigo flow → destination
Celigo can connect to external messaging systems when that architecture makes sense.
Celigo Topics adds another option: a native topic-based messaging layer inside Celigo.
Producer → Celigo Topic → subscriber flows → destinations
With Celigo Topics, Celigo is not only connecting to somebody else’s broker. Celigo provides the topic-based messaging layer for Celigo flows, so teams can use pub/sub patterns without standing up a separate broker for Celigo-based automation.
Celigo Topics
A Celigo Topic is a named channel that producers publish messages to and one or more flows can subscribe to independently.
Topics help integration specialists decouple producers from consumers. A producer publishes a message to the topic. Each subscriber flow decides how to consume and process that message.
Core publish/subscribe capabilities in Celigo Topics
Celigo Topics supports the core building blocks of native pub/sub messaging:
- Named topics for business events
- Configurable message retention
- Publishing through supported routes, such as an API or flow step
- Subscriber flows that consume messages independently
- Subscriber-owned cursors
- Start position options, such as Latest or Earliest retained
- At-least-once delivery
- Message history for retained messages
- Topic configuration managed inside Celigo
The result is a more flexible architecture for event-driven integration. Teams can publish a business event once and let multiple downstream automations respond in their own way.
Publish once, subscribe many times
Imagine an ecommerce system publishes an OrderCreated message to a Celigo Topic.
From that one publish, several subscriber flows can act independently.
- One flow sends fulfillment details to a 3PL.
- Another creates billing context for finance.
- Another updates an analytics dataset.
- Another triggers an AI-assisted fraud or exception review.
The producer only publishes the event. It does not need to call each downstream flow directly.
That makes the architecture easier to extend. If the analytics team needs a new subscriber next month, they can add one without requiring the producer to change how it publishes orders.
How subscriber-owned cursors isolate downstream failures
In a point-to-point design, one downstream failure can create pressure on the entire process.
With Celigo Topics, each subscriber tracks its own position in the topic.
That means a subscriber can pause, fail, or resume without blocking other subscribers. Within the configured retention window, the subscriber can continue from its own cursor and process retained messages when it comes back online.
This matters in real operations.
A fulfillment subscriber may need to pause while a warehouse system is unavailable. Finance and analytics should not stop processing just because fulfillment is temporarily offline. Each subscriber can continue according to its own state.
Start subscribers from Latest or Earliest retained messages
Different subscribers need different starting behavior.
Some subscribers should only process new messages going forward. Others need to catch up on messages already retained in the topic.
- Celigo Topics supports subscriber start position options such as Latest and Earliest retained.
- Use Latest when a new subscriber should begin with new messages from this point forward.
- Use Earliest retained when a subscriber should start with retained messages still available in the topic.
This gives integration specialists more control when adding new consumers, testing subscriber flows, or recovering from downtime within the retention window.
Why native publish/subscribe messaging matters for integration teams
Add new consumers without changing producers
New subscriber flows can be added without modifying the publishing application or flow.
That makes it easier to extend automation when new teams, systems, or processes need the same business event.
Isolate downstream failures without stopping other subscribers
Each subscriber consumes independently. If one subscriber pauses or fails, other subscribers can continue processing.
Within the retention window, the affected subscriber can resume from its own cursor.
Reuse one business event across multiple automations
A single event can support multiple downstream processes.
An order event can drive fulfillment, billing, reporting, notifications, and AI-assisted review without requiring the producer to send separate messages to each destination.
Keep event-driven integration inside Celigo
Teams can use pub/sub patterns without operating a separate message broker just to fan out events between Celigo flows.
Celigo Topics keeps the event-driven pattern closer to the integrations, flows, and governance model already used by the team.
Example: event fan-out for an OrderCreated event
An OrderCreated event is published to a Celigo Topic.
From there, subscriber flows handle different parts of the business process.
Fulfillment subscriber: Consumes the order event and sends fulfillment details to a warehouse or 3PL.
Finance subscriber: Consumes the same event and creates billing context for invoicing or revenue workflows.
Analytics subscriber: Consumes the event and updates reporting or data warehouse pipelines.
AI review subscriber: Consumes the event and evaluates whether the order needs additional review.
Each subscriber consumes independently. Each can evolve independently. The producer remains simple.
Order producer → Celigo Topic → fulfillment, finance, analytics, AI review
That is a decoupled integration architecture in practice.
Who should use Celigo Topics?
Celigo Topics is built for teams that need more flexible event-driven integration patterns inside Celigo.
It is especially useful for:
- Integration specialists and teams that want to avoid hand-wiring one producer to every downstream flow.
- Teams designing decoupled integration architectures across multiple systems and business processes.
- Operations teams and teams that need one subscriber to pause or recover without blocking other subscribers.
- Business process owners and teams that want the same event to trigger multiple independent workflows.
- AI and automation teams that want business events to initiate agentic, decision, or exception workflows.
- Platform teams that want pub/sub patterns without operating a separate broker for Celigo-based automation.
