Skip to main content
Redhat Developers  Logo
  • Products

    Platforms

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat AI
      Red Hat AI
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • View All Red Hat Products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat Developer Hub
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat OpenShift Local
    • Red Hat Developer Sandbox

      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Secure Development & Architectures

      • Security
      • Secure coding
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • Product Documentation
    • API Catalog
    • Legacy Documentation
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

How to set up event-driven microservices using Knative Eventing

May 2, 2023
Matthias Wessendorf
Related topics:
Event-DrivenKubernetesMicroservicesServerless
Related products:
Streams for Apache KafkaRed Hat OpenShift

Share:

    Many modern application designs are event-driven, aiming to deliver events quickly. This article describes how to orchestrate event-driven microservices using standards like CNCF CloudEvents and Kubernetes APIs for Knative to simplify EDA-style application development.

    The Event Driven Architecture (EDA) allows the implementation of loosely coupled applications and services. In this model, event producers do not know for which event consumers are listening, and the event itself does not know the consequences of its occurrence. EDA is a good option for distributed application architectures.

    Figure 1 illustrates an example of an event-driven application consisting of three services, producing and consuming different events with an event bus responsible for the orchestration and routing of the events. Note that “Service 3” produces an event indicating the business process finished, but there is no consumer for the event.

    Illustration of an event-driven application consisting of three services, producing and consuming different events.
    Figure 1: An event-driven application consisting of three services, producing and consuming different events.

    It is simple to implement another consumer for the “Finish Event” with the flexible architecture of event-driven systems.

    Knative Eventing

    How can you build a system on Kubernetes that orchestrates events and routes them to consumers? Luckily there is Knative Eventing, which offers a collection of APIs that enable cloud native developers to use an event-driven architecture within their applications and services. You can use these APIs to create components that route events from event producers to event consumers, known as sinks, that receive events.

    Knative Eventing uses standard HTTP requests to send and receive events between event producers and sinks. These events conform to a CNCF industry standard called CloudEvents, which enables creating, parsing, sending, and receiving events in any programming language. The binding between the HTTP protocol and CloudEvents is standardized in this specification. Although the focus of this article is on HTTP, it is worth mentioning that the CloudEvents specification also describes bindings for other protocols, such as AMQP or Websocket.

    Event mesh with Knative Broker

    One of the key APIs in Knative Eventing is the Knative Broker API, which defines an event mesh aiding the event orchestration and routing. Figure 2 shows a complete process, covering purchases from an online web shop and ends when the order is completely delivered at the customer's door. The process is implemented by a couple of microservice applications that are consuming and producing events. There is no direct communication or invocation between the services. Instead, the applications are loosely coupled and communicate only via events.

    An illustration of the process flow of an event-driven application.
    Figure 2: The complete process flow of an event-driven application.

    The orchestration of the event exchange is handled by an event mesh. In our case, this is the Knative Broker for Apache Kafka.

    apiVersion: eventing.knative.dev/v1
    kind: Broker
    metadata:
     annotations:
       eventing.knative.dev/broker.class: Kafka
     name: order-broker
    spec:
     config:
       apiVersion: v1
       kind: ConfigMap
       name: order-broker-config
    
    ---
    
    apiVersion: v1
    kind: ConfigMap
    metadata:
     name: order-broker-config
    data:
     bootstrap.servers: <url>
     auth.secret.ref.name: <optional-secret-name>
     default.topic.partitions: "10"
     default.topic.replication.factor: "3"

    The broker is annotated to pick the Kafka-backed implementation and points to a ConfigMap holding configuration about the Apache Kafka Topic, internally used by the broker. Generally, it is also recommended to configure aspects of delivery guarantees and retries. But we skipped this to keep this article simple. For more details on best practices for Knative Broker configurations, read the article, Our advice for configuring Knative Broker for Apache Kafka.

    After the Broker definition has been applied with oc apply, you can check for the broker and its status as follows:

    oc get brokers.eventing.knative.dev -n orders
    NAME           URL                                                                                  AGE   READY
    order-broker   http://kafka-broker-ingress.knative-eventing.svc.cluster.local/orders/order-broker   46m   True

    Every Knative Broker object exposes an HTTP endpoint acting as the Ingress for CloudEvents. The URL can be found on the status of each broker object. The following is an example of an HTTP POST request that could be sent from the “Online Shop” service to the event mesh, aka the Knative Kafka Broker.

    curl -v -X POST \
      -H "content-type: application/json"  \
      -H "ce-specversion: 1.0"  \
      -H "ce-source: /online/shop"  \
      -H "ce-type: order.requested"  \
      -H "ce-id: 1f1380d4-8ff2-4ab0-b2ba-54811226c21b"  \
      -d '{"customerId": 20207-19, "orderId": "f8bc3445-b844"}' \
       http://kafka-broker-ingress.knative-eventing.svc.cluster.local/orders/order-broker

    But how is the event getting delivered to the “Payment Service”, since there is no direct coupling between the two?

    Event orchestration and routing

    While the Broker API implements an event mesh, it goes hand-in-hand with the trigger API, which the broker is using to route messages based on a given set of rules or criteria to their destination.

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      name: trigger-order-requested
    spec:
      broker: order-broker
      filter:
        attributes:
          type: order.requested
          source: /online/shop
      subscriber:
        ref:
          apiVersion:v1
          kind: Service
          name: payment

    This example is a trigger for the “order-broker” which contains two filters, each for different CloudEvent attributes metadata:

    • Type
    • Source

    Both rules are treated as an AND, and the event is only routed to the referenced payment service by the Knative Broker if both rules match.

    The routing of the matching CloudEvent to the referenced Kubernetes Service (payment) is done by the Knative Broker using HTTP. This allows a flexible architecture for the implementation of the processing services since simply all that is needed is a Web Server program, regardless of the written language. Besides the Kubernetes Service API, we can also reference a Knative Serving Service, supporting serverless principals.

    If the referenced service replies with a CloudEvent in its HTTP response, this event is returned back to the Knative Broker and available for further processing. Using a different trigger with a matching rule can route those events to other service applications.

    CloudEvent processing with Knative Functions

    One simple way to create microservices that are processing standard CloudEvents is to leverage the Knative Functions project. It contains templates for a number of languages and platforms, such as:

    • Golang
    • Node.js (JavaScript)
    • Quarkus (Java)
    • Spring Boot (Java)
    • Python
    • Rust

    The following script is the implementation of the “Payment Service” application, which was written based on the Quarkus Funqy template. Funqy is part of Quarkus’s serverless strategy that provides a portable Java API for developers to write serverless functions and deploy them to heterogeneous serverless runtimes, including AWS Lambda, Azure Functions, Google Cloud, and Knative. With Funqy, developers can easily bind their methods to CloudEvents, using the @Funq annotation. Funqy ensures that the @Funq annotated Java method is invoked with the HTTP request from the Knative Broker, containing the “OrderRequested” CloudEvent.

    Note: The OrderRequests object is part of the CloudEvent payload in a serialized JSON format, as indicated by the previous cURL example.

    @Funq
    public CloudEvent<PaymentReceived> orderRequest(final CloudEvent<OrderRequested> order) {
      LOG.debug("Incoming CloudEvent with ID: " + order.id());
      try {
        final PaymentReceived payment = paymentProvider.processPayment(order.data());
        return CloudEventBuilder.create()
               .id(UUID.randomUUID().toString())
               .type("payment.received")
               .source("/payment")
               .build(payment);
      } catch (InvalidPaymentException ipe) {
        // recover from here
        return CloudEventBuilder.create().build(...);
      }
    }
    
    

    The CloudEvent payload is deserialized to the “OrderRequest” type, using the data() method from the CloudEvents API and processed by a payment provider service. Once the payment is approved, the Knative Function code returns a different CloudEvent with type payment.received, indicating the payment has been received.

    Let’s have a look at the diagram in Figure 2 where the “Order Service” subscribed to the “payment.received” event. Whenever such an event is available in the event mesh, the Knative Broker will dispatch it to the subscribed “Order Service” and continue the process of the shopping cart application.

    Note: In case of a failure, we see the InvalidPaymentException and a different CloudEvent with an error type returned to the broker, indicating that a failure has occurred. For more information on how to configure the Knative Broker for delivery guarantees and retries, please refer to the previously mentioned article.

    Using application-specific events

    When working with event-driven microservices, it is highly recommended that every service or function should respond to incoming requests with an outgoing event on its HTTP response. The CloudEvents should be domain-specific and provide context about their state on the CloudEvent metadata attributes. It is very important to not return the same CloudEvent type that goes into a function because this would cause a filter loop on the executing Knative Broker. For successful event processing and domain-specific failures, a service should always return a CloudEvent to the Knative Broker.

    To handle network-level failures occurring while the Knative Broker tries to deliver the CloudEvents (such as HTTP 4xx/5xx errors), we recommend configuring a Dead-Letter-Sink for improved delivery guarantees.

    Knative Eventing simplifies event-driven microservices

    The article described how the Knative Eventing Broker and Trigger APIs help to orchestrate event-driven microservices. The architecture is based on standardized Kubernetes APIs for Knative and CNCF CloudEvents. We also discussed how the implementation of EDA-style applications are loosely coupled and how to implement a simple routing approach for events using Knative Eventing. Leveraging industry standards is a good investment for any application architecture. If you have questions, please comment below. We welcome your feedback.

    Last updated: January 22, 2024

    Related Posts

    • Our advice for configuring Knative Broker for Apache Kafka

    • How Knative broker GA enhances Kafka on OpenShift Serverless

    • Orchestrate event-driven, distributed services with Serverless Workflow and Kubernetes

    • Event-driven business automation powered by cloud-native Java

    • Knative Cookbook: Building Effective Serverless Applications with Kubernetes and OpenShift

    Recent Posts

    • How to enable Ansible Lightspeed intelligent assistant

    • Why some agentic AI developers are moving code from Python to Rust

    • Confidential VMs: The core of confidential containers

    • Benchmarking with GuideLLM in air-gapped OpenShift clusters

    • Run Qwen3-Next on vLLM with Red Hat AI: A step-by-step guide

    What’s up next?

    knative cookbook

    Download Knative Cookbook and learn how to efficiently build, deploy, and manage modern serverless workloads. You'll also explore how to apply Knative in real enterprise scenarios, including advanced eventing.

    Get the e-book
    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue