Weik.io

Eventing Overview

CloudEvents-based event messaging with NATS JetStream

System integration is rarely clean. Services fail, networks drop, and payloads don’t match the documentation. Weik.io’s eventing system tries to make this chaos manageable by standardizing everything on CloudEvents. We use NATS JetStream to store the events and Apache Camel Kamelets to actually move them around.

What is Eventing?

Instead of point-to-point spaghetti connections, Weik.io routes everything through a central messaging backbone. External systems push data in, we convert it to the CloudEvents standard, store it in NATS JetStream, and pass it along to whoever subscribed to listen. It’s a standard pub/sub model, but strictly enforcing CloudEvents makes debugging significantly less painful.

Core Components

Events

Every message moving through the system is a CloudEvent. This means you always get a predictable envelope with standard attributes—like type, source, id, and time—wrapped around your actual data.

Event Sources

Event Sources are where data enters the system. Under the hood, they use Apache Camel Kamelets to connect to external APIs, databases, or message brokers. Once data arrives, the source converts it to a CloudEvent and drops it into a dedicated NATS JetStream stream.

Configuration example:

apiVersion: weik.io/v1alpha1
kind: EventSource
metadata:
  name: s3-events
spec:
  type: aws-s3-source
  parameters:
    bucketNameOrArn: "my-bucket"
    region: "eu-west-1"

Check the Event Sources reference to see what else you can connect to.

Event Channels

If sources pull data in, channels push data out. Event Channels take CloudEvents and use Camel Kamelets to deliver them to external targets.

Configuration example:

apiVersion: weik.io/v1alpha1
kind: EventChannel
metadata:
  name: webhook-channel
spec:
  type: http
  parameters:
    url: "https://example.com/webhook"
    method: "POST"

See Event Channels for the full list of delivery options.

Event Subscriptions

Sources and channels don’t know about each other. Event Subscriptions bridge the gap by routing events from a specific source to a specific channel.

Configuration example:

apiVersion: weik.io/v1alpha1
kind: EventSubscription
metadata:
  name: s3-to-webhook
spec:
  source: s3-events
  channel: webhook-channel

See Event Subscriptions for more details.

Streams

Underneath it all, NATS JetStream stores the events. This gives you a durable, ordered log. If a target system goes down, the events wait in the stream instead of vanishing into the ether.

Event Flow

The actual lifecycle is straightforward:

  1. An Event Source grabs data from an external system.
  2. It publishes a CloudEvent to a NATS stream.
  3. An Event Subscription picks up the event.
  4. An Event Channel pushes it to the target system.

Supported Patterns

Publish-Subscribe

You can attach multiple channels to a single source. Each subscription gets its own consumer, so one slow API won’t block other systems from getting the same event.

Event Replay

Because NATS keeps a record, you can replay events from the past. When a downstream system inevitably crashes and loses a day’s worth of data, you can just replay the stream from yesterday to fix it.

Configuration

You configure these components with YAML. Since hardcoding secrets in YAML is a terrible idea, we support variable substitution.

Example with variables:

apiVersion: weik.io/v1alpha1
kind: EventSource
metadata:
  name: s3-events
spec:
  type: aws-s3-source
  parameters:
    accessKey: "{{accessKey}}"
    secretKey: "{{secretKey}}"
  variables:
    - accessKey: "{{sys:AWS_ACCESS_KEY}}"
    - secretKey: "{{sys:AWS_SECRET_KEY}}"

See Variables to learn how to manage secrets safely.

What’s Next