# 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

      # 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

    # data:
      # This section allows to configure Zeebe's data storage. Data is stored in
      # "partition folders". A partition folder has the following structure:
      #
      # partition-0                       (root partition folder)
      # ├── partition.json                (metadata about the partition)
      # ├── segments                      (the actual data as segment files)
      # │   ├── 00.data
      # │   └── 01.data
      # └── state                     	(stream processor state and snapshots)
      #     └── stream-processor
      #		  ├── runtime
      #		  └── snapshots

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

      # 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: 15m

      # 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.
      #
      # This setting can also be overridden using the environment variable ZEEBE_BROKER_DATA_DISKUSAGEMONITORINGENABLED
      # diskUsageMonitoringEnabled = true

      # 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

      # 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

      # 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

    # 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;

      # 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: "vegas"

      # 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: "1s"

        # 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

    # 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
        #
        #     numberOfShards: 3
        #     numberOfReplicas: 0
        #
        #     command: false
        #     event: true
        #     rejection: false
        #
        #     deployment: false
        #     process: true
        #     error: true
        #     incident: true
        #     job: true
        #     jobBatch: false
        #     message: false
        #     messageSubscription: false
        #     variable: true
        #     variableDocument: true
        #     processInstance: true
        #     processInstanceCreation: false
        #     processMessageSubscription: false

    # 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
        # requestTimeout = 5s

        # 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

      # 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 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. It's currently disabled by default as
        # performance is a bit less predictable when disabling the WAL.
        # This setting can also be set using the environment variable ZEEBE_BROKER_EXPERIMENTAL_ROCKSDB_DISABLEWAL
        # disableWal: false

      # 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
