NATS JetStream over Kafka for event ingestion

architecturenatsdistributed-systems

Context

Building a distributed analytics and feature-flag backend for a SaaS client. Multiple Golang services needed to publish events reliably. The team was small and already used NATS for service messaging.

Decision

Use NATS JetStream as the durable event bus — one stream per domain, pull consumers writing to DuckDB, push consumers for feature-flag evaluation.

Alternatives Considered

Apache Kafka

Pros
  • Industry standard for high-volume event streaming
  • Rich ecosystem of connectors
Cons
  • Operational overhead disproportionate for team size
  • New infrastructure skill for a team already on NATS

Direct HTTP ingestion to DuckDB

Pros
  • Simplest architecture
Cons
  • No buffering during spikes
  • Tight coupling between producers and analytics store

Redis streams only

Pros
  • Already in the stack for session data
Cons
  • Weak story for long retention and replay
  • Analytics queries still need a separate store

Reasoning

JetStream gave durable streams, replay, and consumer groups without a second message platform. The Golang NATS client is mature. For the client's event volume, JetStream was sufficient and the ops surface area stayed small.

All decisions