Producer Model

Summary

The Producer Model defines how Integration Hub's Event Processor categorizes ingested events and routes them to domain-specific outbox topics. Each incoming EventHubEvent is classified by its operationType and resourceType into one of four domains: user lifecycle, access/session, policy/client management, or organization. The Event Processor then wraps the event into an OutboxEvent envelope for each matching subscription and publishes it to the corresponding outbox topic. This domain-based routing ensures that downstream delivery processors handle only events relevant to their domain.

Why It Exists

A single undifferentiated outbox topic would create two problems:

1. Consumer overload — The Outbox Processor would need to process all events regardless of domain, reducing throughput and complicating error isolation
2. DLT noise — When a subscriber for one domain fails, its DLT events would mix with other domains, making operator triage difficult

By routing events to domain-specific outbox topics, Integration Hub achieves domain isolation: each topic and its corresponding DLT can be monitored, scaled, and managed independently.

Where It Fits in Keymate

The Producer Model operates within the Event Processor service, between the ingestion surface and the event-driven distribution layer. It receives raw events, resolves subscriptions via the Consumer Model, and produces OutboxEvent envelopes to domain outbox topics.

Boundaries

In scope:

• Event categorization by operationType and resourceType
• Domain-to-topic mapping logic
• OutboxEvent envelope creation with subscription metadata
• Event bus producer channels and configuration

Out of scope:

• Event ingestion → gRPC Ingestion Surface
• Subscription registration and resolution → Consumer Model
• HTTP delivery and retry → Connector & Delivery Model and Connector Runtime

How It Works

Event Categorization

The Event Processor categorizes each event by its operationType or resourceType into one of four domains:

Domain	Event Categories	Example Operations
User Lifecycle	User creation, updates, deletion, registration, password resets, role assignments, email verification	CREATE, UPDATE, DELETE, REGISTER, PASSWORD-RESET, ASSIGN, VERIFY_EMAIL
Access / Session	Authentication events, token operations, session management	LOGIN, LOGOUT, CODE_TO_TOKEN, REFRESH_TOKEN, TOKEN_EXCHANGE, IDENTITY_PROVIDER_LOGIN
Policy / Client	Client registration, consent management, policy grants	CLIENT_REGISTER, CLIENT_UPDATE, CLIENT_DELETE, GRANT_CONSENT, REVOKE_GRANT
Organization	Organization membership, invitations, org lifecycle	INVITE_ORG, CREATE (org), DELETE (org), ASSIGN (org membership), SELECT, UNASSIGN

Outbox Topic Structure

Each domain maps to a dedicated outbox topic and a corresponding DLT topic:

Domain	Topic Pattern	DLT Topic Pattern
User Lifecycle	Dedicated outbox topic	Corresponding .DLT topic
Access / Session	Dedicated outbox topic	Corresponding .DLT topic
Policy / Client	Dedicated outbox topic	Corresponding .DLT topic
Organization	Dedicated outbox topic	Corresponding .DLT topic

All topics follow a platform-defined naming convention. Each outbox topic has a paired DLT topic with the .DLT suffix.

Each outbox topic has a corresponding delivery channel in the Event Processor.

Processing Pipeline

For each ingested event, the Event Processor executes the following processing pipeline:

1. Extract — The event's sourceService, eventType, resourceType, and operationType are extracted from the EventHubEvent (handling both user events and admin events)
2. Resolve — A subscription lookup key is built from the extracted fields
3. Lookup — The Subscription Management service is queried via gRPC to find all active subscriptions matching the event key
4. Loop — For each active subscription (executed in parallel):
   • The event is wrapped into an OutboxEvent with the subscriber's endpoint, auth, and protocol
   • The domain topic is determined based on the event's operation/resource type
   • The OutboxEvent is emitted to the corresponding outbox topic channel

OutboxEvent Envelope

The OutboxEvent protobuf is the output of the Producer Model:

OutboxEvent proto structure

message OutboxEvent {
  EventHubEvent event = 1;      // Original platform event
  string protocol = 2;          // "http", "grpc", "event-bus"
  string endpoint = 3;          // Subscriber delivery URL
  SubscriberAuth auth = 4;      // Authentication credentials
}

Each subscription produces its own OutboxEvent — if three subscribers match an event, three separate envelopes are published (potentially to different domain topics if the routing logic differs).

Event Bus Producer Configuration

All outgoing channels share the same configuration pattern:

Property	Value	Description
Connector	Event bus connector	Standard event bus integration
Topic	Domain-specific outbox topic	One topic per domain category
Serializer	Protobuf serializer	Serializes OutboxEvent messages in Protobuf format
Schema Registry	Configurable	Schema Registry address

Diagram

Example Scenario

Scenario

A user login event is ingested. Two subscribers are registered for access events with different endpoints.

Input

• Actor: Identity provider (event source)
• Resource: EventHubEvent with operationType: LOGIN
• Action: Event Processor categorizes and routes
• Context: Two active subscriptions exist for access events

Expected Outcome

1. Event Processor extracts operationType: LOGIN → categorized as Access / Session domain
2. Subscription lookup returns 2 active subscriptions
3. Two OutboxEvent envelopes are created (one per subscriber, each with different endpoint and auth)
4. Both are published to the Access outbox topic
5. Outbox Processor consumes and delivers to both subscriber endpoints

Common Misunderstandings

• "Events are duplicated across topics" — Each event is routed to exactly one domain topic based on its categorization. The fan-out happens at the subscription level (multiple OutboxEvent envelopes per matching subscriber), not at the topic level.

• "Topic routing is configurable per subscription" — Topic routing is determined by the event's operation/resource type, not by the subscription. Subscriptions determine who receives the event; routing determines which topic carries the envelope.

warning

If an event's operationType or resourceType does not match any known category, the event may be dropped without delivery. Ensure that new operation types are added to the event categorization configuration when extending the platform.

Design Notes / Best Practices

• Keep event categories exhaustive — When introducing new event types to the platform, update the event categorization configuration to include the new operation/resource type in the appropriate domain category.

• Parallel subscription processing — The Event Processor processes multiple subscriptions in parallel. This ensures that a large number of subscriptions for a single event does not become a bottleneck.

tip

The four domain topics provide a natural scaling boundary. If one domain generates significantly more traffic than others, the corresponding Outbox Processor can be scaled independently.

Next Step

Continue with Consumer Model to learn how subscriptions are registered and resolved during event routing.

Related Docs

gRPC Ingestion Surface

How events enter the Event Processor.

Consumer Model

How subscriptions are registered and resolved.

Event-Driven Distribution

The full domain-based routing and fan-out model.

Connector & Delivery Model

How OutboxEvents are delivered to subscriber endpoints.