Ironflow PubSub Flow

Ironflow PubSub Flow A data-flow diagram generated by Archify. 01 / Source 02 / Outbox 03 / Bridge 04 / PUBSUB 05 / Consume Engine / executor · run + step changes · 01 / Source Engine / executor run + step changes Event write · one transaction · 01 / Source Event write one transaction Outbox rows · drained later · 02 / Outbox · issue #487 Outbox rows drained later issue #487 EventPublisher · topic to subject · 03 / Bridge EventPublisher topic to subject PUBSUB stream · public.>, 7 days · 04 / PUBSUB · notifications only PUBSUB stream public.>, 7 days notifications only WebSocket / gRPC · ephemeral consumer · 05 / Consume WebSocket / gRPC ephemeral consumer Consumer groups · durable membership · 05 / Consume Consumer groups durable membership system.* and topic:{name} events + entity rows outbox worker drains public.{envID}.… replay + CEL filter at-least-once to one member Legend primary data data store data flow

Subject mapping

  • • system.run.{id}.completed to public.{envID}.system.run.{id}.completed
  • • events:{name} to public.{envID}.events.{name}
  • • entity:{type}.{id}.{event} to public.{envID}.entity.{type}.{id}.{event}
  • • topic:{name} to public.{envID}.topic.{name}

Two ways in, one mapping

  • • system.* and topic:{name} are published in-process by the engine
  • • events:{name} and entity events are outbox rows in the event's transaction
  • • The subject mapping is identical either way — only the caller differs

Notifications only

  • • Consuming PUBSUB never writes to the DB — the DB stays the source of truth
  • • Subscribers get an ephemeral consumer per pattern, replay up to 1000
  • • Groups keep membership in consumer_groups (internal/pubsub)