broker.yaml.template

# Zeebe Broker configuration file (without embedded gateway)

# ! ! ! ! ! ! ! ! ! !
# In order to activate the settings in this file, rename this file to application.yaml.
# ! ! ! ! ! ! ! ! ! !

# Overview -------------------------------------------

# This file contains a complete list of available configuration options.

# This file shows example values for configuring several exporters. To enable an exporter
# please uncomment the whole block and overwrite the settings.

# Conventions:
#
# Byte sizes
# For buffers and others must be specified as strings and follow the following
# format: "10U" where U (unit) must be replaced with KB = Kilobytes, MB = Megabytes or GB = Gigabytes.
# If unit is omitted then the default unit is simply bytes.
# Example:
# sendBufferSize = "16MB" (creates a buffer of 16 Megabytes)
#
# Time units
# Timeouts, intervals, and the likes, must be specified either in the standard ISO-8601 format used
# by java.time.Duration, or as strings with the following format: "VU", where:
#   - V is a numerical value (e.g. 1, 5, 10, etc.)
#   - U is the unit, one of: ms = Millis, s = Seconds, m = Minutes, or h = Hours
#
# Paths:
# Relative paths are resolved relative to the installation directory of the broker.
# ----------------------------------------------------

# zeebe:
  # broker:
    # gateway:
      # Enable the embedded gateway to start on broker startup.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_GATEWAY_ENABLE.
      # enable: false

    # network:
      # This section contains the network configuration. Particularly, it allows to
      # configure the hosts and ports the broker should bind to. The broker exposes two sockets:
      # 1. command: the socket which is used for gateway-to-broker communication
      # 2. internal: the socket which is used for broker-to-broker communication

      # Controls the default host the broker should bind to. Can be overwritten on a
      # per binding basis for client, management and replication
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_HOST.
      # host: 0.0.0.0

      # Controls the advertised host; if omitted defaults to the host. This is particularly useful if your
      # broker stands behind a proxy.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_ADVERTISEDHOST.
      # advertisedHost: 0.0.0.0

      # If a port offset is set it will be added to all ports specified in the config
      # or the default values. This is a shortcut to not always specifying every port.
      #
      # The offset will be added to the second last position of the port, as Zeebe
      # requires multiple ports. As example a portOffset of 5 will increment all ports
      # by 50, i.e. 26500 will become 26550 and so on.
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_PORTOFFSET.
      # portOffset: 0

      # Sets the maximum size of the incoming and outgoing messages (i.e. commands and events).
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_MAXMESSAGESIZE.
      # maxMessageSize: 4MB

      # security:
        # Enables TLS authentication between this gateway and other nodes in the cluster
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_SECURITY_ENABLED.
        # enabled: false

        # Sets the path to the certificate chain file.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_SECURITY_CERTIFICATECHAINPATH.
        # certificateChainPath:

        # Sets the path to the private key file location
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_SECURITY_PRIVATEKEYPATH.
        # privateKeyPath:

      # commandApi:
        # Overrides the host used for gateway-to-broker communication
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_COMMANDAPI_HOST.
        # host: 0.0.0.0

        # Sets the port used for gateway-to-broker communication
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_COMMANDAPI_PORT.
        # port: 26501

        # Controls the advertised host; if omitted defaults to the host. This is particularly useful if your
        # broker stands behind a proxy.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_COMMANDAPI_ADVERTISEDHOST.
        # advertisedHost: 0.0.0.0

        # Controls the advertised port; if omitted defaults to the port. This is particularly useful if your
        # broker stands behind a proxy.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_COMMANDAPI_ADVERTISEDPORT.
        # advertisedPort: 25601

      # internalApi:
        # Overrides the host used for internal broker-to-broker communication
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_INTERNALAPI_HOST.
        # host: 0.0.0.0

        # Sets the port used for internal broker-to-broker communication
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_INTERNALAPI_PORT.
        # port: 26502

        # Controls the advertised host; if omitted defaults to the host. This is particularly useful if your
        # broker stands behind a proxy.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_INTERNALAPI_ADVERTISEDHOST.
        # advertisedHost: 0.0.0.0

        # Controls the advertised port; if omitted defaults to the port. This is particularly useful if your
        # broker stands behind a proxy.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_NETWORK_INTERNALAPI_ADVERTISEDPORT.
        # advertisedPort: 25602

    # data:
      # This section allows to configure Zeebe's data storage. Data is stored in
      # "partition folders". A partition folder has the following structure:
      #
      # partitions
      #  └── 1                       (root partition folder)
      #      ├── 1.log
      #      ├── 2.log
      #      └── snapshots
      #          └── <snapshot-id>
      #     		      └── xx.sst
      #      └── runtime
      #          └── yy.sst

      # Specify the directory in which data is stored.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DIRECTORY.
      # directory: data

      # Specify the directory in which runtime is stored.
      # By default runtime is stored in `directory` for data.
      # If runtimeDirectory is configured, then the configured directory will be used. It will have a subdirectory for each partition to store its runtime.
      # There is no need to store runtime in a persistent storage. This configuration allows to split runtime to another disk to optimize for performance and disk usage.
      # Note: If runtime is another disk than the data directory, files need to be copied to data directory while taking snapshot. This may impact disk i/o or performance during snapshotting.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_RUNTIMEDIRECTORY.
      # runtimeDirectory: null

      # The size of data log segment files.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_LOGSEGMENTSIZE.
      # logSegmentSize: 128MB

      # How often we take snapshots of streams (time unit)
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_SNAPSHOTPERIOD.
      # snapshotPeriod: 5m

      # Configure whether to monitor disk usage to prevent out of disk space issues.
      # If set to false the broker might run out of disk space and end in a non recoverable state.
      # If set to true the disk space will be monitored and the broker will reject commands and pause replication
      # if the thresholds of diskUsageCommandWatermark and diskUsageReplicationWatermark are reached.
      #
      # DEPRECATED. Use zeebe.broker.data.disk.enableMonitoring
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISKUSAGEMONITORINGENABLED
      # diskUsageMonitoringEnabled = true

      # DEPRECATED. Use zeebe.broker.data.disk.freeSpace.processing
      # When the disk usage is above this value all client commands will be rejected.
      # The value is specified as a percentage of the total disk space.
      # The value should be in the range (0, 1].
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISKUSAGECOMMANDWATERMARK
      # diskUsageCommandWatermark = 0.97

      # DEPRECATED. Use zeebe.broker.data.disk.freeSpace.replication
      # When the disk usage is above this value, this broker will stop writing replicated events it receives from other brokers.
      # The value is specified as a percentage of the total disk space.
      # The value should be in the range (0, 1].
      # It is recommended that diskUsageReplicationWatermark > diskUsageCommandWatermark
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISKUSAGEREPLICATIONWATERMARK
      # diskUsageReplicationWatermark = 0.99

      # DEPRECATED. Use zeebe.broker.data.disk.monitoringInterval.
      # Sets the interval at which the disk usage is monitored
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISKUSAGEMONITORINGINTERVAL
      # diskUsageMonitoringInterval = 1s

      # disk:
        # Configure disk monitoring to prevent getting into a non-recoverable state due to out of disk space.
        # When monitoring is enabled, the broker rejects commands and pause replication when the required freeSpace is not available.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISK_ENABLEMONITORING
        # enableMonitoring: true

        # Sets the interval at which the disk usage is monitored
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISK_MONITORINGINTERVAL
        # monitoringInterval: 1s

        # freeSpace:
          # When the free space available is less than this value, this broker rejects all client commands and pause processing.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISK_FREESPACE_PROCESSING
          # processing: 2GB

          # When the free space available is less than this value, broker stops receiving replicated events.
          # This value must be less than freeSpace.processing. It is recommended to configure free space
          # large enough for at least one log segment and one snapshot. This is because a partition needs
          # enough space to take a new snapshot to be able to compact the log segments to make disk space available again.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISK_FREESPACE_REPLICATION
          # replication: 1GB

      # backup:
        # Configure backup store. NOTE:- Use the same configuration on all brokers of this cluster.

        # Set the backup store type. Supported values are [NONE, S3, GCS, AZURE]. Default value is NONE
        # When NONE, no backup store is configured and no backup will be taken.
        # Use S3 to use any S3 compatible storage (https://docs.aws.amazon.com/AmazonS3/latest/API/Type_API_Reference.html).
        # Use GCS to use Google Cloud Storage (https://cloud.google.com/storage/)
        # Use AZURE to use Azure Storage (https://learn.microsoft.com/en-us/azure/storage/)
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_STORE
        # store: NONE

        # Configure the following if store is set to S3
        # s3:

          # Name of the bucket where the backup will be stored.
          # The bucket must be already created. The bucket must not be shared with other zeebe clusters. bucketName must not be empty.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_BUCKETNAME
          # bucketName:

          # Configure URL endpoint for the store.
          # If no endpoint is provided, it will be determined based on the configured region.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_ENDPOINT
          # endpoint:

          # Configure AWS region. If no region is provided it will be determined as documented in
          # https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/region-selection.html#automatically-determine-the-aws-region-from-the-environment
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_REGION
          # region:

          # Configure access credentials. If either accessKey or secretKey is not provided, the credentials
          # will be determined as documented in https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/credentials.html#credentials-chain
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_ACCESSKEY
          # accessKey:
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_SECRETKEY
          # secretKey:

          # Configure a maximum duration for all S3 client API calls.
          # Lower values will ensure that failed or slow API calls don't block other backups but may increase the risk
          # that backups can't be stored if uploading parts of the backup takes longer than the configured timeout.
          # See https://github.com/aws/aws-sdk-java-v2/blob/master/docs/BestPractices.md#utilize-timeout-configurations
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_APICALLTIMEOUT
          # apiCallTimeout: PT180S

          # When enabled, forces the s3 client to use path-style access. By default, the client will automatically
          # choose between path-style and virtual-hosted-style. Should only be enabled if the s3 compatible storage cannot
          # support virtual-hosted-style.
          # See https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-bucket-intro.html
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_FORCEPATHSTYLEACCESS
          # forcePathStyleAccess: false

          # When set to an algorithm such as 'zstd', enables compression of backup contents.
          # When not set or set to 'none', backup content is not compressed.
          # Enabling compression reduces the required storage space for backups in S3 but also
          # increases the impact on CPU and disk utilization while taking a backup.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_COMPRESSION
          # compression: none

          # When set, all objects in the bucket will use this prefix. Must be non-empty and not start or end with '/'.
          # Useful for using the same bucket for multiple Zeebe clusters. In this case, basePath must be unique.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_S3_BASEPATH
          # basePath:

        # Configure the following if store is set to GCS
        # gcs:
          # Name of the bucket where the backup will be stored.
          # The bucket must already exist.
          # The bucket must not be shared with other Zeebe clusters unless basePath is also set.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_GCS_BUCKETNAME
          # bucketName:

          # When set, all blobs in the bucket will use this prefix.
          # Useful for using the same bucket for multiple Zeebe clusters. In this case, basePath must be unique.
          # Should not start or end with '/' character. Must be non-empty and not consist of only '/' characters.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_GCS_BASEPATH
          # basePath:

          # When set, this overrides the host that the GCS client connects to.
          # By default, this is not set because the client can automatically discover the correct host to
          # connect to.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_GCS_HOST
          # host:

          # Configures which authentication method is used for connecting to GCS. Can be either 'auto' or 'none'.
          # Choosing 'auto' means that the GCS client uses application default credentials which automatically
          # discovers appropriate credentials from the runtime environment: https://cloud.google.com/docs/authentication/application-default-credentials
          # Choosing 'none' means that no authentication is attempted which is only applicable for testing with emulated GCS.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_GCS_AUTH.
          # auth: auto

        # Configure the following if store is set to AZURE
        # azure:
          # Azure endpoint to connect to. Required unless a connection string is specified.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_AZURE_ENDPOINT
          # endpoint:

          # Account name used to authenticate with Azure.
          # Can only be used in combination with an account key.
          # If account credentials or connection string are not provided, authentication will use credentials from the
          # runtime environment: https://learn.microsoft.com/en-us/java/api/com.azure.identity.defaultazurecredential?view=azure-java-stable
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_AZURE_ACCOUNTNAME
          # accountName:

          # Account key that is used to authenticate with Azure.
          # Can only be used in combination with an account name.
          # If account credentials or connection string are not provided, authentication will use credentials from the
          # runtime environment: https://learn.microsoft.com/en-us/java/api/com.azure.identity.defaultazurecredential?view=azure-java-stable
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_AZURE_ACCOUNTKEY
          # accountKey:

          # The connection string configures endpoint, account name and account key all at once.
          # If neither connection string, account name, nor account key are defined, the azure client uses
          # If connection string or account credentials are not provided, authentication will use credentials from the
          # runtime environment: https://learn.microsoft.com/en-us/java/api/com.azure.identity.defaultazurecredential?view=azure-java-stable
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_AZURE_CONNECTIONSTRING
          # connectionString:

          # Defines the container name where backup contents are saved.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_BACKUP_AZURE_BASEPATH
          # basePath:

    # cluster:
      # This section contains all cluster related configurations, to setup a zeebe cluster

      # Specifies the unique id of this broker node in a cluster.
      # The id should be between 0 and number of nodes in the cluster (exclusive).
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_NODEID.
      # nodeId: 0

      # Controls the number of partitions, which should exist in the cluster.
      #
      # This can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_PARTITIONSCOUNT.
      # partitionsCount: 1

      # Controls the replication factor, which defines the count of replicas per partition.
      # The replication factor cannot be greater than the number of nodes in the cluster.
      #
      # This can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_REPLICATIONFACTOR.
      # replicationFactor: 1

      # Specifies the zeebe cluster size. This value is used to determine which broker
      # is responsible for which partition.
      #
      # This can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_CLUSTERSIZE.
      # clusterSize: 1

      # Allows to specify a list of known other nodes to connect to on startup
      # The contact points of the internal network configuration must be specified.
      # The format is [HOST:PORT]
      # Example:
      # initialContactPoints : [ 192.168.1.22:26502, 192.168.1.32:26502 ]
      #
      # To guarantee the cluster can survive network partitions, all nodes must be specified
      # as initial contact points.
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_INITIALCONTACTPOINTS
      # specifying a comma-separated list of contact points.
      # Default is empty list:
      # initialContactPoints: []

      # Allows to specify a name for the cluster
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_CLUSTERNAME.
      # Example:
      # clusterName: zeebe-cluster

      # Configure heartbeatInterval. The leader sends a heartbeat to a follower every heartbeatInterval.
      # Note: This is an advanced setting.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_HEARTBEATINTERVAL.
      # heartbeatInterval: 250ms

      # Configure electionTimeout. If a follower does not receive a heartbeat from the leader with in an election timeout,
      # it can start a new leader election. electionTimeout should be greater than configured heartbeatInterval.
      # When the electionTimeout is large, there will be delay in detecting a leader failure.
      # When the electionTimeout is small, it can lead to false positives when detecting leader failures and thus leading to unnecessary leader changes.
      # If the network latency between the nodes is high, it is recommended to have a higher election latency.
      # Note: This is an advanced setting.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_ELECTIONTIMEOUT.
      # electionTimeout: 2500ms

      # Configure raft properties
      # raft:
        # When this flag is enabled, the leader election algorithm attempts to elect the leaders based on a pre-defined priority.
        # As a result, it tries to distributed the leaders uniformly across the brokers. Note that it is only a best-effort strategy.
        # It is not guaranteed to be a strictly uniform distribution.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_RAFT_ENABLEPRIORITYELECTION
        # enablePriorityElection = true

        # Configures how often data is explicitly flushed to disk. By default, for a given
        # partition, data is flushed on every leader commit, and every follower append. This is to
        # ensure consistency across all replicas. Disabling this can cause inconsistencies, and at
        # worst, data corruption or data loss scenarios.
        #
        # The default behavior is optimized for safety, and flushing occurs on every leader commit
        # and follower append in a synchronous fashion. You can introduce a delay to reduce the
        # performance penalty of flushing via `delayTime`.
        # flush:
          # If false, explicit flushing of the Raft log is disabled, and flushing only occurs right
          # before a snapshot is taken. You should only disable explicit flushing if you are willing
          # to accept potential data loss at the expense of performance. Before disabling it, try
          # the delayed options, which provide a trade-off between safety and performance.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_RAFT_FLUSH_ENABLED
          # enabled: true
          # If the delay is > 0, then flush requests are delayed by at least the given period. It is
          # recommended that you find the smallest delay here with which you achieve your
          # performance goals. It's also likely that anything above 30s is not useful, as this is
          # the typical default flush interval for the Linux OS.
          # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_RAFT_FLUSH_DELAYTIME
          # delayTime: 0s

      # Configure parameters for SWIM protocol which is used to propagate cluster membership
      # information among brokers and gateways
      # membership:

        # Configure whether to broadcast member updates to all members.
        # If set to false updates will be gossiped among the members.
        # If set to true the network traffic may increase but it reduce the time to detect membership changes.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_BROADCASTUPDATES
        # broadcastUpdates: false

        # Configure whether to broadcast disputes to all members.
        # If set to true the network traffic may increase but it reduce the time to detect membership changes.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_BROADCASTDISPUTES
        # broadcastDisputes: true

        # Configure whether to notify a suspect node on state changes.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_NOTIFYSUSPECT
        # notifySuspect: false

        # Sets the interval at which the membership updates are sent to a random member.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_GOSSIPINTERVAL
        # gossipInterval: 250ms

        # Sets the number of members to which membership updates are sent at each gossip interval.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_GOSSIPFANOUT
        # gossipFanout: 2

        # Sets the interval at which to probe a random member.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_PROBEINTERVAL
        # probeInterval: 1s

        # Sets the timeout for a probe response
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_PROBETIMEOUT
        # probeTimeout: 100ms

        # Sets the number of probes failed before declaring a member is suspect
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_SUSPECTPROBES
        # suspectProbes: 3

        # Sets the timeout for a suspect member is declared dead.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_FAILURETIMEOUT
        # failureTimeout: 10s

        # Sets the interval at which this member synchronizes its membership information with a random member.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MEMBERSHIP_SYNCINTERVAL
        # syncInterval: 10s

      # Configure compression algorithm for all message sent between the brokers and between the broker and
      # the gateway. Available options are NONE, GZIP and SNAPPY.
      # This feature is useful when the network latency between the brokers is very high (for example when the brokers are deployed in different data centers).
      # When latency is high, the network bandwidth is severely reduced. Hence enabling compression helps to improve the throughput.
      # Note: When there is no latency enabling this may have a performance impact.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_CLUSTER_MESSAGECOMPRESSION
      # messageCompression: NONE

    # threads:
      # Controls the number of non-blocking CPU threads to be used. WARNING: You
      # should never specify a value that is larger than the number of physical cores
      # available. Good practice is to leave 1-2 cores for ioThreads and the operating
      # system (it has to run somewhere). For example, when running Zeebe on a machine
      # which has 4 cores, a good value would be 2.
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_THREADS_CPUTHREADCOUNT
      # cpuThreadCount: 2

      # Controls the number of io threads to be used. These threads are used for
      # workloads that write data to disk. While writing, these threads are blocked
      # which means that they yield the CPU.
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_THREADS_IOTHREADCOUNT
      # ioThreadCount: 2

    # backpressure:
      # Configure backpressure below.
      #
      # Set this to enable or disable backpressure. When enabled the broker rejects user requests when
      # the number of inflight requests is greater than than the "limit". The value of the "limit" is determined
      # based on the configured algorithm.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_ENABLED
      # enabled : true

      # if enabled - will use the average latencies over a window as the current latency to update the limit.
      # It is not recommended to enable this when the algorithm is aimd. This setting is not applicable to fixed limit.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_USEWINDOWED
      # useWindowed: true

      # The algorithm configures which algorithm to use for the backpressure.
      # It should be one of vegas, aimd, fixed, gradient, or gradient2.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_ALGORITHM
      # algorithm: "aimd"

      # Configure the parameters for "aimd" algorithm.
      # AIMD increases the limit for every successful response and decrease the limit for every request timeout.
      # aimd:
        # The limit will be reduced if the observed latency is greater than the requestTimeout.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_AIMD_REQUESTTIMEOUT
        # requestTimeout: "200ms"

        # The initial limit to be used when the broker starts. The limit will be reset to this value when the broker restarts.
        # This setting can also be overridden using the environment ZEEBE_BROKER_BACKPRESSURE_AIMD_INITIALLIMIT
        # initialLimit: 100

        # The minimum limit. This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_AIMD_MINLIMIT
        # minLimit: 1

        # The maximum limit. This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_AIMD_MAXLIMIT
        # maxLimit: 1000

        # The backoffRatio is a double value x such that 0 <  x  < 1. It determines the factor by which the limit is decreased.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_AIMD_BACKOFFRATIO
        # backoffRatio: 0.9

      # Configure the parameters for "fixed" algorithm
      # fixed:
        # Set a fixed limit. This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_FIXED_LIMIT
        # limit: 20

      # Configure the parameters for "vegas" algorithm
      # Vegas is an adaptive limit algorithm based on TCP Vegas congestion control algorithm.
      # It estimates a queue size which indicates how many additional requests are in the queue over the estimated limit.
      # The limit is adjusted based on this queueSize.
      # vegas:
        # The initial limit to be used when the broker starts. The limit will be reset to this value when the broker restarts.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_VEGAS_INITIALLIMIT
        # initialLimit: 20

        # The limit is increased if the queue size is less than this value.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_VEGAS_ALPHA
        # alpha: 3

        # The limit is decreased if the queue size is greater than this value.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_VEGAS_BETA
        # beta: 6

      # Configure the parameters for "gradient" algorithm
      # In gradient algorithm, the limit is adjusted based on the gradient of observed latency and an estimated minimum latency.
      # If gradient is less than 1, the limit is decreased otherwise the limit is increased.
      # gradient:
        # The minimum limit. This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_GRADIENT_MINLIMIT
        # minLimit: 10

        # The initial limit to be used when the broker starts. The limit will be reset to this value when the broker restarts.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_GRADIENT_INITIALLIMIT
        # initialLimit: 20

        # Tolerance for changes from minimum latency. A value >= 1.0 indicating how much change from minimum latency is acceptable
        # before reducing the limit.  For example, a value of 2.0 means that a 2x increase in latency is acceptable.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_GRADIENT_RTTTOLERANCE
        # rttTolerance: 2.0

      # Configure the parameters for "gradient2" algorithm
      # gradient2:
        # The minimum limit. This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_GRADIENT2_MINLIMIT
        # minLimit: 10

        # The initial limit to be used when the broker starts. The limit will be reset to this value when the broker restarts.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_GRADIENT2_INITIALLIMIT
        # initialLimit: 20

        # Tolerance for changes from minimum latency. A value >= 1.0 indicating how much change from minimum latency is acceptable
        # before reducing the limit.  For example, a value of 2.0 means that a 2x increase in latency is acceptable.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_BACKPRESSURE_GRADIENT2_RTTTOLERANCE
        # rttTolerance: 2.0

        # longWindow is the length of the window (the number of samples) to calculate the exponentially smoothed average latency.
        # This setting can also be overridden using the environment ZEEBE_BROKER_BACKPRESSURE_GRADIENT2_LONGWINDOW
        # longWindow: 600

    # exporting:
      # This section contains definitions common to all exporters.
      #
      # Enable the exporters to skip record position.
      # These setting can also be overridden using the environment variables "ZEEBE_BROKER_EXPORTING_SKIPRECORDS"
      # Allows to skip certain records by their position. This is useful for debugging or skipping a record that is
      # preventing processing or exporting to continue.
      # Record positions defined to skip in this definition will be skipped in all exporters.
      # The value is a comma-separated list of records ids to skip. Whitespace is ignored.
      # skipRecords:

    # exporters:
      # Configure exporters below
      #
      # Each exporter should be configured following this template:
      #
      # jarPath:
      #   path to the JAR file containing the exporter class. JARs are only loaded once, so you can define
      #   two exporters that point to the same JAR, with the same class or a different one, and use args
      #   to parametrize its instantiation.
      # className:
      #   entry point of the exporter, a class which *must* extend the io.camunda.zeebe.exporter.Exporter
      #   interface.
      #
      # A nested table as "args:" will allow you to inject arbitrary arguments into your
      # class through the use of annotations.
      #
      # These setting can also be overridden using the environment variables "ZEEBE_BROKER_EXPORTERS_[exporter name]_..."
      #

      # Debug Log Exporter --------------
      #
      # Enable the following debug exporter to log the exported records to console
      #
      # These setting can also be overridden using the environment variables "ZEEBE_BROKER_EXPORTERS_DEBUGLOG_..."
      #
      # debuglog:
        # className: io.camunda.zeebe.broker.exporter.debug.DebugLogExporter
        # args:
        #   logLevel: debug
        #   prettyPrint: false

      # Debug HTTP Export ---------------
      #
      # Enable the following debug exporter to start a http server to inspect the exported records
      #
      # These setting can also be overridden using the environment variables "ZEEBE_BROKER_EXPORTERS_DEBUGHTTP_..."
      #
      # debugHttp:
        # className: io.camunda.zeebe.broker.exporter.debug.DebugHttpExporter
        # args:
        #   port = 8000
        #   limit = 1024

      # Elasticsearch Exporter ----------
      # An example configuration for the elasticsearch exporter:
      #
      # These setting can also be overridden using the environment variables "ZEEBE_BROKER_EXPORTERS_ELASTICSEARCH_..."
      #
      # elasticsearch:
        # className: io.camunda.zeebe.exporter.ElasticsearchExporter
        #
        # args:
        #   url: http://localhost:9200
        #
        #   bulk:
        #     delay: 5
        #     size: 1000
        #     memoryLimit: 10485760
        #
        #   authentication:
        #     username: elastic
        #     password: changeme
        #
        #   index:
        #     prefix: zeebe-record
        #     createTemplate: true
        #
        #     # Pattern based on https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/format/DateTimeFormatter.html
        #     indexSuffixDatePattern = "yyyy-MM-dd"
        #
        #     numberOfShards: 3
        #     numberOfReplicas: 0
        #
        #     command: false
        #     event: true
        #     rejection: false
        #
        #     commandDistribution: true
        #     compensationSubscription: true
        #     decisionRequirements: true
        #     decision: true
        #     decisionEvaluation: true
        #     deployment: true
        #     deploymentDistribution: true
        #     error: true
        #     escalation: true
        #     form: true
        #     incident: true
        #     job: true
        #     jobBatch: false
        #     message: true
        #     messageBatch: false
        #     messageStartSubscription: true
        #     messageSubscription: true
        #     process: true
        #     processEvent: false
        #     processInstance: true
        #     processInstanceBatch: false
        #     processInstanceCreation: true
        #     processInstanceMigration: true
        #     processInstanceModification: true
        #     processMessageSubscription: true
        #     resourceDeletion: true
        #     signal: true
        #     signalSubscription: true
        #     timer: true
        #     userTask: true
        #     variable: true
        #     variableDocument: true
        #
        #   retention:
        #     enabled: false
        #     minimumAge: 30d
        #     policyName: zeebe-record-retention-policy

      # Opensearch Exporter ----------
      # An example configuration for the opensearch exporter:
      #
      # These setting can also be overridden using the environment variables "ZEEBE_BROKER_EXPORTERS_OPENSEARCH_..."
      #
      # opensearch:
        # className: io.camunda.zeebe.exporter.opensearch.OpensearchExporter
        #
        # args:
        #   url: http://localhost:9200
        #   requestTimeoutMs: 1000
        #
        #   bulk:
        #     delay: 5
        #     size: 1000
        #     memoryLimit: 10485760
        #
        #   retention:
        #     enabled: false
        #     minimumAge: 30d
        #     policyName: zeebe-record-retention-policy
        #     policyDecsription: Zeebe record retention policy
        #
        #   authentication:
        #     username: opensearch
        #     password: changeme
        #
        #   aws:
        #     enabled: true
        #     serviceName: es
        #     region: eu-west-1
        #
        #   index:
        #     prefix: zeebe-record
        #     createTemplate: true
        #
        #     numberOfShards: 3
        #     numberOfReplicas: 0
        #
        #     command: false
        #     event: true
        #     rejection: false
        #
        #     commandDistribution: true
        #     compensationSubscription: true
        #     decisionRequirements: true
        #     decision: true
        #     decisionEvaluation: true
        #     deployment: true
        #     deploymentDistribution: true
        #     error: true
        #     escalation: true
        #     form: true
        #     incident: true
        #     job: true
        #     jobBatch: false
        #     message: true
        #     messageBatch: false
        #     messageStartSubscription: true
        #     messageSubscription: true
        #     process: true
        #     processEvent: false
        #     processInstance: true
        #     processInstanceBatch: false
        #     processInstanceCreation: true
        #     processInstanceMigration: true
        #     processInstanceModification: true
        #     processMessageSubscription: true
        #     resourceDeletion: true
        #     signal: true
        #     signalSubscription: true
        #     timer: true
        #     userTask: true
        #     variable: true
        #     variableDocument: true

    # processing:
      # Sets the maximum number of commands that processed within one batch.
      # The processor will process until no more follow up commands are created by the initial command
      # or the configured limit is reached.
      # By default, up to 100 commands are processed in one batch. Can be set to 1 to disable batch processing.
      # Must be a positive integer number.
      # Note that the resulting batch size will contain more entries than this limit because it includes follow up events.
      # When resulting batch size is too large (see maxMessageSize), processing will be rolled back and retried with a smaller maximum batch size.
      # Lowering the command limit can reduce the frequency of rollback and retry.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_PROCESSING_MAXCOMMANDSINBATCH
      # maxCommandsInBatch = 100

      # Allows scheduled processing tasks such as checking for timed-out jobs to run concurrently to
      # regular processing. This is a performance optimization to ensure that processing is not interrupted by
      # higher than usual workload for any of the scheduled tasks. This should only be disabled in case of bugs,
      # for example if one of the scheduled tasks is not safe to run concurrently to regular processing.
      #
      # This replaces the deprecated experimental settings that enable async scheduling for specific tasks only, for
      # example `enableMessageTTLCheckerAsync`. When `enableAsyncScheduledTasks` is enabled (which it is by default),
      # the deprecated settings take no effect. When `enableAsyncScheduledTasks` is disabled, scheduled tasks are only run async
      # if explicitly enabled by the deprecated setting.
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_PROCESSING_ENABLEASYNCSCHEDULEDTASKS
      # enableAsyncScheduledTasks: true

      # Allows to skip certain commands by their position. This is useful for debugging and data recovery.
      # It is not recommended to use this in production.
      # The value is a comma-separated list of positions to skip. Whitespace is ignored.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_PROCESSING_SKIPPOSITIONS
      # skipPositions: ""
    # experimental
      # Be aware that all configuration's which are part of the experimental section
      # are subject to change and can be dropped at any time.
      # It might be that also some of them are actually dangerous so be aware when you change one of these!

      # Sets the maximum of appends which are send per follower.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_MAXAPPENDSPERFOLLOWER
      # maxAppendsPerFollower = 2

      # Sets the maximum batch size, which is send per append request to a follower.
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_MAXAPPENDBATCHSIZE
      # maxAppendBatchSize = 32KB;

      # This setting allows you to configure how partitions are distributed amongst the node of the
      # clusters. It currently supports to partitioning schemes: ROUND_ROBIN, and FIXED.
      #
      # ROUND_ROBIN is the default partitioning scheme. To enable it, set `scheme` to `ROUND_ROBIN`;
      # not extra configuration is required. To understand how it will distribute the partitions,
      # refer to the documentation:
      #   https://docs.camunda.io/docs/product-manuals/zeebe/technical-concepts/partitions#partition-distribution
      #
      # The FIXED partitioning scheme allows users with non-traditional deployments to manual
      # distribute the partitions across their set of brokers. This can be useful, for example, if
      # you want to deploy a cluster across multiple data centers with some replication guarantees.
      # See below for details on how to configure it.
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_PARTITIONING
      # partitioning:
        # The partitioning scheme to use. Can be one of: ROUND_ROBIN, FIXED. Defaults to
        # ROUND_ROBIN.
        # scheme: ROUND_ROBIN
        #
        # The FIXED partitioning scheme configuration. This must be an exhaustive mapping of all
        # partitions to a set of brokers. If any partitions are not configured, the broker will not
        # start.
        #
        # For each partition, you must specify its partition ID (ranging from 1 to
        # partitionCount), and the set of nodes which will manage it. This must be a subset
        # of nodes whose IDs are valid within your cluster. This means with node IDs ranging from 0
        # to the (clusterSize - 1), without any repeated IDs. This subset must have the same amount
        # of nodes as the replication factor, otherwise the broker will not start.
        #
        # If you are using priority election, then you can also specify the priorities for each
        # nodes. Note that for a given partition, the priorities of each member must be different,
        # otherwise the broker will fail to start.
        #
        # fixed:
        #   - partitionId: 1
        #     nodes:
        #       - nodeId: 0
        #         priority: 1
        #       - nodeId: 1
        #         priority: 2
        #       - nodeId: 2
        #         priority: 3
        #   - partitionId: 2
        #     nodes:
        #       - nodeId: 0
        #         priority: 3
        #       - nodeId: 1
        #         priority: 2
        #       - nodeId: 2
        #         priority: 1
        #   - partitionId: 3
        #     nodes:
        #       - nodeId: 0
        #         priority: 2
        #       - nodeId: 1
        #         priority: 3
        #       - nodeId: 2
        #         priority: 2

      # Allows to configure experimental raft properties
      # raft:
        # Sets the timeout for all requests send by raft leaders and followers.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_RAFT_REQUESTTIMEOUT
        # When modifying the values for requestTimeout, it might also be useful to update snapshotTimeout.
        # requestTimeout: 2500ms

        # Sets the timeout for all snapshot requests sent by raft leaders to the followers.
        # If the network latency between brokers is high, it would help to set a higher timeout here.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_RAFT_SNAPSHOTREQUESTTIMEOUT.
        # snapshotRequestTimeout: 2500ms

        # Sets the timeout for configuration change requests such as joining or leaving. Since changes are usually a multi-step
        # process with multiple commits, a higher timeout than the default requestTimeout is recommended.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_RAFT_CONFIGURATIONCHANGEREQUESTTIMEOUT.
        # configurationChangeRequestTimeout: 10000ms

        # If the leader is not able to reach the quorum, the leader may step down.
        # This is triggered after a number of requests, to a quorum of followers, has failed, and the number of failures
        # reached minStepDownFailureCount. The maxQuorumResponseTime also influences when the leader step down.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_RAFT_MINSTEPDOWNFAILURECOUNT
        # minStepDownFailureCount: 3

        # If the leader is not able to reach the quorum, the leader may step down.
        # This is triggered if the leader is not able to reach the quorum of the followers for maxQuorumResponseTimeout.
        # The minStepDownFailureCount also influences when the leader step down.
        # Higher the timeout, slower the leader reacts to a partial network partition.
        # When the timeout is lower, there might be false positives, and the leader might step down too quickly.
        # When this value is 0, it will use a default value of electionTimeout * 2.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_RAFT_MAXQUORUMRESPONSETIMEOUT
        # maxQuorumResponseTimeout: 0ms

        # Threshold used by the leader to decide between replicating a snapshot or records.
        # The unit is number of records by which the follower may lag behind before the leader
        # prefers replicating snapshots instead of records.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_RAFT_PREFERSNAPSHOTREPLICATIONTHRESHOLD.
        # preferSnapshotReplicationThreshold: 100

        # Defines whether segment files are pre-allocated to their full size on creation or not. If
        # true, when a new segment is created on demand, disk space will be reserved for its full
        # maximum size. This helps avoid potential out of disk space errors which can be fatal when
        # using memory mapped files, especially when running on network storage. In the best cases,
        # it will also allocate contiguous blocks, giving a small performance boost.
        #
        # You may want to turn this off if your system does not support efficient file allocation
        # via system calls, or if you notice an I/O penalty when creating segments.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_RAFT_PREALLOCATESEGMENTFILES.
        # preallocateSegmentFiles: true

      # Allows to configure RocksDB properties, which is used for state management.
      # rocksdb:
        # Specify custom column family options overwriting Zeebe's own defaults.
        # WARNING: This setting requires in-depth knowledge of Zeebe's embedded database: RocksDB.
        # The expected property key names and values are derived from RocksDB's C implementation,
        # and are not limited to the provided examples below. Please look in RocksDB's SCM repo
        # for the files: `cf_options.h` and `options_helper.cc`. This setting can also be overridden
        # using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_COLUMNFAMILYOPTIONS_{PROPERTY_KEY_NAME}
        # For example, `write_buffer_size` can be set using `ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_COLUMNFAMILYOPTIONS_WRITE_BUFFER_SIZE`.
        # columnFamilyOptions:
          # compaction_pri: "kOldestSmallestSeqFirst"
          # write_buffer_size: 67108864

        # Enables RocksDB statistics, which will be written to the RocksDB log file.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_ENABLESTATISTICS
        # enableStatistics: false

        # Configures which, if any, RocksDB column family access metrics are exposed.
        # Valid values are none (the default), and fine which exposes many metrics covering the read, write, delete and iteration
        # latency per partition and column family.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_ENABLEACCESSMETRICS
        # accessMetrics: none

        # Configures the memory limit, which can be used by RocksDB. Be aware that this setting only applies to RocksDB, which is used by the Zeebe's state management and that
        # an RocksDB instance is used per partition.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_MEMORYLIMIT
        # memoryLimit: 512MB

        # Configures how many files are kept open by RocksDB, per default it is unlimited (-1).
        # This is a performance optimization: if you set a value greater than zero, it will keep track and cap the number of open
        # files in the TableCache. On accessing the files it needs to look them up in the cache.
        # You should configure this property if the maximum open files are limited on your system, or if you have thousands of files in your RocksDB state as there is a memory overhead to keeping all of them open, and setting maxOpenFiles will bound that.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_MAXOPENFILES
        # maxOpenFiles: -1

        # Configures the maximum number of simultaneous write buffers/memtables RocksDB will have in memory. Normally about 2/3s of the memoryLimit
        # is used by the write buffers, and this is shared equally by each write buffers. This means the higher maxWriteBufferNumber is, the less
        # memory is available for each. This means you will flush less data at once, but may flush more often.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_MAXWRITEBUFFERNUMBER
        # maxWriteBufferNumber: 6

        # Configures how many write buffers should be full before they are merged and flushed to disk. Having a higher number here means you may
        # flush less often, but will flush more data at once. Have a lower one means flushing more often, but flushing less data at once.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_MINWRITEBUFFERNUMBERTOMERGE
        # minWriteBufferNumberToMerge: 3

        # Configures a rate limit for write I/O of RocksDB. Setting any value less than or equal to 0 will disable this, which is the default setting.
        # Setting a rate limit on the write I/O can help achieve more stable performance by avoiding write spikes consuming all available IOPS, leading to
        # more predictable read rates.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_IORATEBYTESPERSECOND
        # ioRateBytesPerSecond: 0

        # Configures if the RocksDB write-ahead-log is used or not. By default, every write in RocksDB goes to the active write buffer and the WAL; this
        # helps recover a RocksDB instance should it crash before the write buffer is flushed. Zeebe however only recovers from specific point-in-time snapshot,
        # and never from a previously active RocksDB instance, which makes it a good candidate to disable the WAL.
        # WAL is disabled by default as it can improve performance of Zeebe.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_DISABLEWAL
        # disableWal: true

        # Configures if the RocksDB SST files should be partitioned based on some virtual column families.
        # By default RocksDB will not partition the SST files, which might have influence on the compacting of certain key ranges.
        # Enabling this option gives RocksDB some good hints how to improve compaction and reduce the write amplification.
        # Benchmarks have show impressive results allowing to sustain performance on larger states. This setting will
        # increase the general file count of runtime and snapshots.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_ENABLESSTPARTITIONING
        # enableSstPartitioning: true

      # consistencyChecks:
        # Configures if the basic operations on RocksDB, such as inserting or deleting key-value pairs, should check preconditions,
        # for example that a key does not already exist when inserting.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_CONSISTENCYCHECKS_ENABLEPRECONDITIONS
        # enablePreconditions: false

        # Configures if inserting or updating key-value pairs on RocksDB should check that foreign keys exist.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_CONSISTENCYCHECKS_ENABLEFOREIGNKEYCHECKS
        # enableForeignKeyChecks: false

      # Allows to configure the query API. By default, the broker only offers a command API, which
      # is used by the gateway to pass commands it received along to the broker. Commands can then
      # be processed. Zeebe does not directly support querying of brokers, instead it provides a way
      # to export data to data lakes that can be queried. In highly specific cases, direct querying
      # of a broker is necessary. For this, Zeebe provides a specialized query API. This query API
      # can provide the `BPMN Process Id` belonging to a job, process instance or process
      # definition. For easy access, a Java interface is provided to gateway interceptors, which
      # you can retrieve using
      # `io.camunda.zeebe.gateway.interceptors.InterceptorUtil.getQueryApiKey()`. Please read our
      # documentation on interceptors to learn more about creating and loading interceptors into the
      # gateway. In addition, please have a look at the Javadoc on InterceptorUtil.getQueryApiKey()
      # to see how to use this in practise.
      # queryApi:
        # Enables the query api in the broker.
        # This setting can also be set using the environmentvariable ZEEBE_BROKER_EXPERIMENTAL_QUERYAPI_ENABLED
        # enabled: false

      # engine:
        # messages:
          # Allows to configure the Message TTL Checker's batch limit. This is the number of buffered
          # messages that it can expire in a single batch. When it reaches this limit, it expires
          # another batch of buffered messages. When there are no messages in the buffer past their
          # Time-To-Live, then it goes idle, and reschedules itself after an interval defined with
          # `ttlCheckerInterval`. The batch of message expirations is processed on the stream processor
          # blocking other stream processing activities like process execution and job activation/completion.
          # A smaller batch limit will thus enable greater concurrency with the other stream processing activities.
          # A larger batch limit can allow faster message expiration, but at the cost of blocking the other
          # stream processing activities for extended periods. Defaults to MAX_INTEGER (2^31-1).
          # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ENGINE_MESSAGES_TTLCHECKERBATCHLIMIT
          # ttlCheckerBatchLimit: 0x7fffffff

          # Allows to configure the Message TTL Checker's interval. This is the period during which the
          # checker is idle in between two of its executions. Note that it can expire multiple batches
          # of messages in a single execution. See `ttlCheckerBatchLimit` to configure the size of these batches.
          # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ENGINE_MESSAGES_TTLCHECKERINTERVAL
          # ttlCheckerInterval: 1m

        # caches:
          # Allows to configure the Decision Requirements Graph cache size. By default this is set to 1000.
          # If there are more than 1000 different DRG's actively used in the cluster it is recommended
          # to increase the size of this cache. The cache prevents having to parse DRG's everytime a
          # decision is evaluated. If the cache is full, the least used DRG gets evicted.
          # drgCacheCapacity: 1000

        # jobs:
          # Allows to configure the Job Timeout Checker's polling interval. This is the period during
          # which the checker is idle in between two of its executions. Note that it can mark multiple jobs
          # as timed-out in a single execution. See `timeoutTriggerBatchLimit` to configure the size of these batches.
          # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ENGINE_JOBS_TIMEOUTCHECKERPOLLINGINTERVAL
          # timeoutCheckerPollingInterval: 1s

          # Allows to configure the Job Timeout Checker's batch limit. This is the number of jobs
          # that could be marked as timed-out in a single trigger run.
          # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ENGINE_JOBS_TIMEOUTCHECKERBATCHLIMIT
          # timeoutCheckerBatchLimit: 0x7fffffff

      # Allows to configure feature flags. These are used to test new features in dev and int environments prior
      # to rolling them out to production
      # features:
        # Changes the DueDateTimerChecker to give yield to other processing steps in situations where
        # it has many (i.e. millions of) timers to process. If set to false (default) the DueDateTimerChecker will activate all
        # due timers. In the worst case, this can lead to the node being blocked for indefinite amount of time,
        # being subsequently flagged as unhealthy. Currently, there is no known way to recover from this situation
        # If set to true, the DueDateTimerChecker will give yield to other processing steps. This avoids the worst case
        # described above. However, under consistent high load it may happen that the activated timers will fall behind real time,
        # if more timers become due than can be activated during a certain time period.
        #
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_FEATURES_ENABLEYIELDINGDUEDATECHECKER
        # enableYieldingDueDateChecker: true

        # Controls whether to collect metrics about actor usage such as actor job execution latencies
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_FEATURES_ENABLEACTORMETRICS
        # enableActorMetrics: false

        # While disabled, checking the Time-To-Live of buffered messages blocks all other executions
        # that occur on the stream processor, including process execution and job activation/completion.
        # When enabled, the Message TTL Checker will run asynchronous to the Engine's stream processor.
        # This helps improve throughput and process latency in use cases that publish many messages
        # with a non-zero TTL. We recommend testing this feature in a non-production environment before
        # enabling it in production.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_FEATURES_ENABLEMESSAGETTLCHECKERASYNC
        # enableMessageTTLCheckerAsync: false

        # While disabled, checking for due timers blocks all other executions that occur on the
        # stream processor, including process execution and job activation/completion.
        # When enabled, the Due Date Checker will run asynchronous to the Engine's stream processor.
        # This helps improve throughput and process latency when there are a lot of timers.
        # We recommend testing this feature in a non-production environment before enabling it in production.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_FEATURES_ENABLETIMERDUEDATECHECKERASYNC
        # enableTimerDueDateCheckerAsync: false

        # When enabled, the broker relies on the new cluster topology management to determine partition distribution.
        # When disabled, the broker generates partition distribution on every restart from the provided cluster configuration.
        # This feature should be enabled to use dynamic scaling feature.
        # This setting can also be overridden using the environment variable ZEEBE_BROKER_EXPERIMENTAL_FEATURES_ENABLEDYNAMICCLUSTERTOPOLOGY
        # enableDynamicClusterTopology: true