Understanding Event‑Driven Architecture with Knative Eventing, Serverless and EventBridge

In 2018 Gartner listed the Event‑Driven Model as one of the top ten strategic technology trends, highlighting Event‑Driven Architecture (EDA) as a major driver for software development.

EDA decouples components in distributed systems by using asynchronous publish/subscribe communication instead of direct request‑response calls. Events can represent user actions, system state changes, sensor data, etc.

Knative Serverless Eventing is an open‑source, Kubernetes‑based framework that provides cloud‑native, cross‑platform serverless orchestration. It implements event‑driven capabilities through the Knative Eventing component, which uses standard HTTP POST and the CloudEvents specification to exchange events.

The core of Knative Eventing is the Broker/Trigger model. A Broker acts as an event ingress, while Trigger objects define routing rules and destinations. The event mesh connects producers and consumers via brokers, supporting various underlying channels such as InMemoryChannel, Kafka or NATS Streaming.

Typical event sources include APIServerSource , PingSource , KafkaSource , RabbitMQ , GitHub , GitLab , RedisSource , and many third‑party integrations.

Event forwarding follows a flow like:

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: default
spec:
  config:
    apiVersion: v1
    kind: ConfigMap
    name: config-br-default-channel
  delivery:
    backoffDelay: PT0.2S
    backoffPolicy: exponential
    retry: 10

Ingress receives events and forwards them to the channel (e.g., InMemoryChannel). The imc‑dispatcher fan‑out service distributes events to Filter services, which apply Trigger‑defined filters before delivering to the final subscriber URI.

Event orchestration is expressed with custom resources:

apiVersion: flows.knative.dev/v1
kind: Sequence
metadata:
  name: sequence
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel
  steps:
  - ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: first
  - ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: second
  - ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: third
  reply:
    ref:
      kind: Service
      apiVersion: serving.knative.dev/v1
      name: event-display

A Parallel workflow runs multiple branches concurrently:

apiVersion: flows.knative.dev/v1
kind: Parallel
metadata:
  name: demo-parallel
  namespace: default
spec:
  branches:
  - subscriber:
      ref:
        apiVersion: v1
        kind: Service
        name: demo-ksvc1
  - subscriber:
      ref:
        apiVersion: v1
        kind: Service
        name: demo-ksvc2
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel

Knative Eventing can be combined with Alibaba Cloud EventBridge , a serverless event bus that supports CloudEvents 1.0, offering high‑throughput, disaster‑recovery, schema management, observability and cross‑region routing.

Compared with KEDA, which only autosscales containers based on event metrics, Knative Eventing provides a full‑stack event routing, filtering and orchestration framework.

A demo scenario illustrates a “thirst” use‑case: a PingSource emits a “thirst” event every hour, which triggers a Sequence that calls a Qwen LLM service for a decision and finally invokes a drink‑svc to simulate drinking water.

apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: ping-source
spec:
  schedule: "* */1 * * *"
  contentType: "application/json"
  data: '{"model": "qwen", "messages": [{"role": "user", "content": "渴了"}], "max_tokens": 10, "temperature": 0.7, "top_p": 0.9, "seed": 10}'
  sink:
    ref:
      apiVersion: flows.knative.dev/v1
      kind: Sequence
      name: sequence

The final output shows the LLM response and the action "drink water" printed by the service.

In summary, Knative Eventing offers an open‑source, cloud‑native serverless framework for building scalable, loosely‑coupled event‑driven applications, and it can be extended with EventBridge or compared with KEDA depending on the use case.