Event Stream Governance
Governance extends beyond REST. Hexarch manages Kafka and Pulsar topics with the same rigor as API endpoints.
Event-driven architectures need the same controls as synchronous APIs: who can produce, who can consume, what rate limits apply, and what happens when things go wrong.
Topic Management
Register and govern event topics across your organization:
| Attribute | Description |
|---|---|
| Topic name | Unique identifier (e.g., order.created, iot.telemetry) |
| Broker | Kafka or Pulsar |
| Partitions | Parallelism configuration (3-64 typical) |
| Retention | How long messages are kept (1 hour to 7 days) |
| Throughput SLA | Guaranteed message rate |
| Lifecycle state | Draft, Published, Deprecated, Retired |
Topics follow the same lifecycle as APIs. Deprecated topics show migration guidance. Retired topics reject new connections.
Producer Governance
Control who can write to topics:
Registration
- Producer identity (e.g., “Web-Store-Service”, “Mobile-App-Gateway”)
- Authentication type (mTLS, OAuth2, SASL/SCRAM)
- Rate limits (messages per second)
- Data volume limits (MB/hour)
Enforcement
- Rate limiting at the gateway
- Authentication verification
- Quota tracking and alerting
Status Tracking
- Connected, Idle, Throttled
- Real-time throughput metrics
- Error rate monitoring
Consumer Governance
Control who can read from topics:
Registration
- Consumer identity (e.g., “Shipping-Worker”, “Analytics-ETL”)
- Authentication credentials
- Rate limits (optional—some consumers are unlimited)
- Consumer group assignment
Monitoring
- Connection status
- Consumer lag (message backlog)
- Throughput metrics
- Error patterns
Observability
Real-time metrics for every topic:
- Throughput: Messages in/out per second
- Error rate: Failed deliveries or processing errors
- Consumer lag: How far behind consumers are
- Partition distribution: Load across partitions
Charts show 20-point time series for trend analysis. Alerts trigger on threshold breaches.
Topic Configuration
Governance policies per topic:
Retention
- 1 hour (high-velocity, ephemeral)
- 24 hours (operational data)
- 7 days (audit and compliance)
Partitioning
- Low (3 partitions) for ordered, low-volume topics
- High (64 partitions) for high-throughput, parallelized workloads
Rate Limiting
- Per-producer message rate caps
- Per-consumer read rate caps
- Burst buffers for spikes
Participant SLAs
Define service level agreements for producers and consumers:
| SLA Type | Description |
|---|---|
| Throughput guarantee | Minimum messages/second |
| Latency bound | Maximum delivery latency |
| Availability | Uptime commitment |
| Error threshold | Maximum acceptable error rate |
SLAs are enforced at the gateway. Violations are logged and can trigger alerts.
Why this matters
Without Event Stream Governance:
- Topic creation is ad-hoc
- Producer/consumer access is untracked
- Rate limiting is inconsistent or absent
- Incidents start with “who’s writing to this topic?”
With Hexarch:
- Topics are registered and governed centrally
- Producers and consumers have formal identities
- Rate limits and quotas are enforced
- Audit trails show access patterns
Supported brokers
- Apache Kafka: Full support with SASL, mTLS, OAuth2
- Apache Pulsar: Full support with topic namespaces
Same governance model, different underlying broker.
Next steps
- Developer Portal — how APIs are governed similarly
- Fleet Governance — how enforcement propagates to nodes
- Cryptographic Audit Chains — how event access is recorded