What is Eventing in Kyma?

Overview

With Kyma Eventing, you can focus on your business workflows and trigger them with events to implement asynchronous flows within Kyma. Generally, eventing consists of event producers (or publishers) and consumers (or subscribers) that send events to or receive events from an event processing backend.

The objective of Eventing in Kyma is to simplify the process of publishing and subscribing to events. Kyma uses proven eventing backend technology to provide a seamless experience to the user with their end-to-end business flows. The user does not have to implement or integrate any intermediate backend or protocol.

Kyma Eventing uses the following technology:

Kyma Eventing flow

Kyma Eventing follows the PubSub messaging pattern: Kyma publishes messages to a messaging backend, which filters these messages and sends them to interested subscribers. Kyma does not send messages directly to the subscribers as shown below:

PubSub

Eventing in Kyma from a user’s perspective works as follows:

  • Offer an HTTP end point, for example a Function to receive the events.
  • Specify the events the user is interested in using the Kyma Subscription CR.
  • Send CloudEvents or legacy events (deprecated) to the following HTTP end points on our Event Publishing Proxy service.
    • /publish for CloudEvents.
    • <application_name>/v1/events for legacy events.

For more information, read the Eventing architecture.

Glossary

  • Event Types
    • CloudEvents: Events that confirm to the CloudEvents specification - a common specification for describing event data. The specification is currently under CNCF.
    • Legacy events (deprecated): Events or messages published to Kyma that do not conform to the CloudEvents specification. All legacy events published to Kyma are converted to CloudEvents.
  • Streams and Consumers
    • Streams: A stream stores messages for the published events. Kyma uses only one stream, with file storage, for all the events. You can configure the retention and delivery policies for the stream, depending on the use case.
    • Consumers: A consumer reads or consumes the messages from the stream. Kyma Subscription creates one consumer for each specified filter. Kyma uses push-based consumers.
  • Delivery Guarantees
    • at least once delivery: With NATS JetStream, Kyma now ensures that for each event published, all the subscribers subscribed to that event receive the event at least once.
    • max bytes and discard policy: NATS JetStream uses these configurations to ensure that no messages are lost when the storage is almost full. By default, Kyma ensures that no new messages are accepted when the storage reaches 90% capacity.

Useful links

Find out more about Eventing by following the links on this page.

To learn more about how Eventing works, see:

  • Eventing architecture - describes how Eventing works and the main actors involved, such as the Eventing Controller and Event Publisher Proxy.
  • Event names - contains information about event names and event name cleanup.
  • EventingBackend CR - describes the EventingBackend custom resource, which shows the current status of Kyma Eventing.
  • Subscription CR - describes the Subscription custom resource, which you need to subscribe to events.
  • CloudEvents - provides information about the CloudEvents specification used in Kyma.
  • NATS JetStream - provides more information about the backend technology behind Eventing in Kyma. Eventing Architecture provides details on the new functionalities and higher qualities of service on top of Core NATS.

To perform tasks with Eventing, go through these tutorials:

To troubleshoot Eventing-related issues:

For other technical resources, check out these links on the Kyma GitHub repository: