Introduction

Our Streams service is a powerful tool for building event-driven architectures. It allows you to publish, subscribe to, and query events.

Tenancy

The service supports multi-tenancy, allowing you to isolate data between tenants. Therefore every request must specify the id of the tenant being used.

Groups

Every subscription to events is part of a group. In case you scale your application horizontally, you can use groups to ensure that only one instance of your application processes events for a given group at a time. This is useful for load balancing and ensuring that events are processed in a single instance, preventing duplicate processing of events.

Broadcast events

You can use the broadcast feature to send events to all subscribers in a group.

Event topics with partial persistence

By default, events are persisted in the database. However, you can configure the service to only persist events until they are consumed by a list of relevant consumers.

Use the CONFIG_FILE environment variable to configure the path to the configuration file.

The configuration file is a YAML file with the following structure:

deleteAfterConsumption:
  topicNameHere:
    requiredConsumptionGroups:
      - appA
      - appB
deleteAfterParallelConsumption:
  topicNameHere:
    requiredConsumptionGroups:
      - appA
      - appB

As events can be handled once by topic level parallelism subscriptions and once by non parallel subscriptions, you can configure the service to delete events after they have been handled by all required consumption groups. This is useful to prevent the event store from growing indefinitely.

Be advised to use this feature with caution: Topics that contain events that contain data that is relevant for longer should not be configured for deletion.