adjust instances of Zeebe gateway and Zeebe broker (#4503)

* adjust instances of Zeebe gateway and Zeebe broker

* add to glossary

docs/apis-tools/java-client-examples/cluster-topology-request.md

@@ -11,7 +11,7 @@ This example shows which broker is leader and follower for which partition. This
 
 ## Prerequisites
 
-Run the Zeebe broker with endpoints, `localhost:8080` (default REST) and `localhost:26500` (default gRPC).
+Run the Zeebe Broker with endpoints `localhost:8080` (default REST) and `localhost:26500` (default gRPC).
 
 ## TopologyViewer.java
 

docs/apis-tools/java-client-examples/data-pojo.md

@@ -10,7 +10,7 @@ description: "Let's analyze the prerequisites and code to handle variables as PO
 
 ## Prerequisites
 
-1. Run the Zeebe broker with endpoint `localhost:26500` (default).
+1. Run the Zeebe Broker with endpoint `localhost:26500` (default).
 2. Run the [deploy a process example](process-deploy.md).
 
 ## HandleVariablesAsPojo.java

docs/apis-tools/java-client-examples/decision-evaluate.md

@@ -6,7 +6,7 @@ description: "Let's dive deeper into Zeebe and Java to evaluate a decision."
 
 ## Prerequisites
 
-1. Run the Zeebe broker with endpoint `localhost:26500` (default).
+1. Run the Zeebe Broker with endpoint `localhost:26500` (default).
 1. Run the [deploy a process example](process-deploy.md). Deploy [`demoDecision.dmn`](https://github.com/camunda-community-hub/camunda-8-examples/blob/main/zeebe-client-plain-java/src/main/resources/demoDecision.dmn) instead of `demoProcess.bpmn`.
 
 ## EvaluateDecisionCreator.java

docs/apis-tools/java-client-examples/job-worker-open.md

@@ -10,7 +10,7 @@ description: "Let's analyze the prerequisites and code to open a job worker."
 
 ## Prerequisites
 
-- Run the Zeebe broker with endpoint `localhost:26500` (default).
+- Run the Zeebe Broker with endpoint `localhost:26500` (default).
 - Run the [deploy a process example](process-deploy.md).
 - Run the [create a process instance example](process-instance-create.md) a few times.
 

docs/apis-tools/java-client-examples/process-deploy.md

@@ -11,7 +11,7 @@ description: "Let's analyze the prerequisites and code to deploy a process using
 
 ## Prerequisites
 
-Run the Zeebe broker with endpoint `localhost:26500` (default).
+Run the Zeebe Broker with endpoint `localhost:26500` (default).
 
 ## ProcessDeployer.java
 

docs/apis-tools/java-client-examples/process-instance-create-nonblocking.md

@@ -6,7 +6,7 @@ description: "Let's analyze the prerequisites and code to create non-blocking pr
 
 ## Prerequisites
 
-1. Run the Zeebe broker with endpoint `localhost:26500` (default).
+1. Run the Zeebe Broker with endpoint `localhost:26500` (default).
 2. Run the [deploy a process example](process-deploy.md).
 
 ## NonBlockingProcessInstanceCreator.java

docs/apis-tools/java-client-examples/process-instance-create-with-result.md

@@ -6,7 +6,7 @@ description: "Let's analyze the prerequisites and code to create a process insta
 
 ## Prerequisites
 
-1. Run the Zeebe broker with endpoint `localhost:26500` (default).
+1. Run the Zeebe Broker with endpoint `localhost:26500` (default).
 1. Run the [deploy a process example](process-deploy.md). Deploy [`demoProcessSingleTask.bpmn`](https://github.com/camunda-community-hub/camunda-8-examples/blob/main/zeebe-client-plain-java/src/main/resources/demoProcessSingleTask.bpmn) instead of `demoProcess.bpmn`.
 
 ## ProcessInstanceWithResultCreator.java

docs/apis-tools/java-client-examples/process-instance-create.md

@@ -6,7 +6,7 @@ description: "Let's dive deeper into Zeebe and Java to create a process instance
 
 ## Prerequisites
 
-1. Run the Zeebe broker with endpoint `localhost:26500` (default).
+1. Run the Zeebe Broker with endpoint `localhost:26500` (default).
 1. Run the [deploy a process example](process-deploy.md).
 
 ## ProcessInstanceCreator.java

docs/components/best-practices/architecture/sizing-your-environment.md

@@ -120,7 +120,7 @@ Using your throughput and retention settings, you can now calculate the required
 
 ## Understanding sizing and scalability behavior
 
-Spinning up a Camunda 8 Cluster means you run multiple components that all need resources in the background, like the Zeebe broker, Elasticsearch (as the database for Operate, Tasklist, and Optimize), Operate, Tasklist, and Optimize. All those components need to be equipped with resources.
+Spinning up a Camunda 8 Cluster means you run multiple components that all need resources in the background, like the Zeebe Broker, Elasticsearch (as the database for Operate, Tasklist, and Optimize), Operate, Tasklist, and Optimize. All those components need to be equipped with resources.
 
 All components are clustered to provide high-availability, fault-tolerance and resiliency.
 

docs/components/zeebe/technical-concepts/architecture.md

@@ -52,7 +52,7 @@ The gateway is stateless and sessionless, and gateways can be added as necessary
 
 ## Brokers
 
-The Zeebe broker is the distributed workflow engine that tracks the state of active process instances.
+The Zeebe Broker is the distributed workflow engine that tracks the state of active process instances.
 
 Brokers can be partitioned for horizontal scalability and replicated for fault tolerance. A Zeebe deployment often consists of more than one broker.
 

docs/guides/getting-started-java-spring.md

@@ -125,7 +125,7 @@ Add the following Maven dependency to your Spring Boot Starter project, replacin
 
 ### Configure the Zeebe client
 
-Open your `src/main/resources/application.yaml` file, and paste the following snippet to connect to the Self-Managed Zeebe broker:
+Open your `src/main/resources/application.yaml` file, and paste the following snippet to connect to the Self-Managed Zeebe Broker:
 
 ```yaml
 camunda:

docs/guides/migrating-from-camunda-7/conceptual-differences.md

@@ -58,7 +58,7 @@ There are several differences between how [multi-tenancy](/self-managed/concepts
 2. In Camunda 7, users can deploy shared resources (processes, decisions, and forms) available to all tenants. In Camunda 8, there are no shared resources. This will be added in the future.
 3. In Camunda 7, data is mapped to a `null` tenant identifier, meaning by default resources are shared. In Camunda 8, data is mapped to the `<default>` tenant identifier when multi-tenancy is disabled.
 4. [Tenant checks in Camunda 7](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#disable-the-transparent-access-restrictions) can be disabled to perform admin/maintenance operations. This can't be done in Camunda 8, but an admin user can be authorized to all tenants, which would result in the same thing.
-5. If a user tries to trigger a command on a resource mapped to multiple tenants in Camunda 7, an exception is thrown, and [the `tenantId` must be explicitly provided](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#run-commands-for-a-tenant). However, the Camunda 7 engine will try to infer the correct `tenantId` as much as possible. Users in Camunda 7 that are authorized for multiple tenants may perform a lot more operations without providing a `tenantId`. This inference in the Zeebe broker doesn't happen in Camunda 8, and Zeebe asks users to provide the `tenantId` explicitly.
+5. If a user tries to trigger a command on a resource mapped to multiple tenants in Camunda 7, an exception is thrown, and [the `tenantId` must be explicitly provided](https://docs.camunda.org/manual/develop/user-guide/process-engine/multi-tenancy/#run-commands-for-a-tenant). However, the Camunda 7 engine will try to infer the correct `tenantId` as much as possible. Users in Camunda 7 that are authorized for multiple tenants may perform a lot more operations without providing a `tenantId`. This inference in the Zeebe Broker doesn't happen in Camunda 8, and Zeebe asks users to provide the `tenantId` explicitly.
 
 ## Process solutions using Spring Boot
 
@@ -123,7 +123,7 @@ With Camunda 7 a typical deployment includes:
 With Camunda 8 you deploy:
 
 - Your Spring Boot application with all custom code and the Zeebe client embedded. This application is typically scaled to at least two instances (for resilience)
-- The Zeebe broker, typically scaled to at least three instances (for resilience)
+- The Zeebe Broker, typically scaled to at least three instances (for resilience)
 - An elastic database (for Operate, Tasklist, and Optimize)
 - Optimize, Operate, and Tasklist (each one is a Java application). You can scale those applications to increase availability if you want.
 

docs/reference/glossary.md

@@ -10,13 +10,13 @@ Synonym to "[Connector](#connector)".
 
 ### Broker
 
-A broker is an instance of a Zeebe installation which executes processes and manages process state. A single broker is installed on a single machine.
+The [Zeebe Broker](#zeebe-broker) is the distributed workflow engine that tracks the state of active process instances. However, a Zeebe deployment often consists of more than one broker. Brokers can be partitioned for horizontal scalability and replicated for fault tolerance.
 
-- [Architecture](/components/zeebe/technical-concepts/architecture.md#brokers)
+- [Architecture](/components/zeebe/technical-concepts/architecture.md)
 
 ### Client
 
-A client interacts with the Zeebe broker on behalf of the business application. Clients poll for work from the broker.
+A client interacts with the Zeebe Broker on behalf of the business application. Clients poll for work from the broker.
 
 - [Architecture](/components/zeebe/technical-concepts/architecture.md#clients)
 
@@ -82,12 +82,6 @@ In a clustered environment, a broker which is not a leader is a follower of a gi
 
 - [Clustering](/components/zeebe/technical-concepts/clustering.md#raft-consensus-and-replication-protocol)
 
-### Gateway
-
-Clients communicate with the Zeebe cluster through a gateway. The gateway provides a REST and gRPC API and forwards client commands to the cluster. Depending on the setup, a gateway can be embedded in the broker or can be configured to be standalone.
-
-- [Architecture](/components/zeebe/technical-concepts/architecture.md#gateways)
-
 ### Human task
 
 Camunda 8 allows you to orchestrate processes with human tasks, which may be [user tasks](#user-task) or [manual tasks](#manual-task).
@@ -175,7 +169,7 @@ Outbound [Connectors](#connector) in Camunda 8 allow workflows to trigger with e
 
 ### Partition
 
-A partition represents a logical grouping of data in a Zeebe broker. This data includes process instance variables stored in RocksDB, commands, and events generated by Zeebe stored in the log. The number of partitions is defined by configuration.
+A partition represents a logical grouping of data in a Zeebe Broker. This data includes process instance variables stored in RocksDB, commands, and events generated by Zeebe stored in the log. The number of partitions is defined by configuration.
 
 - [Partitions](/components/zeebe/technical-concepts/partitions.md)
 
@@ -293,3 +287,13 @@ See [process instance](#process-instance).
 ### Workflow instance variable
 
 See [process instance variable](#process-instance-variable).
+
+## Zeebe Broker
+
+The [Zeebe Broker](/components/zeebe/technical-concepts/architecture.md#brokers) is the distributed workflow engine that tracks the state of active process instances. The Zeebe Broker is the main part of the Zeebe cluster, which does all the heavy work like processing, replicating, exporting, and everything based on partitions.
+
+### Zeebe Gateway
+
+The Zeebe Gateway is a component of the Zeebe cluster; it can be considered the contact point for the Zeebe cluster which allows Zeebe clients to communicate with Zeebe brokers inside a Zeebe cluster.
+
+- [Zeebe Gateway overview](/self-managed/zeebe-deployment/zeebe-gateway/zeebe-gateway-overview.md)

docs/self-managed/about-self-managed.md

@@ -38,4 +38,4 @@ In this configuration, Camunda 8 Self-Managed can be accessed as follows:
 - Identity, Operate, Optimize, Tasklist, Modeler: `https://camunda.example.com/[identity|operate|optimize|tasklist|modeler]`
   - Web Modeler also exposes a WebSocket endpoint on `https://camunda.example.com/modeler-ws`. This is only used by the application itself and should not be accessed by users directly.
 - Keycloak authentication: `https://camunda.example.com/auth`
-- Zeebe gateway: `grpc://zeebe.camunda.example.com`
+- Zeebe Gateway: `grpc://zeebe.camunda.example.com`

docs/self-managed/concepts/multi-region/dual-region.md

@@ -98,11 +98,11 @@ Amazon OpenSearch is **not supported** in dual-region configurations.
 - Required open ports between the two regions:
   - **9200** for Elasticsearch (for cross-region data pushed by Zeebe).
   - **26500** for communication to the Zeebe Gateway from clients/workers.
-  - **26501** and **26502** for communication between Zeebe brokers and Zeebe Gateway.
+  - **26501** and **26502** for communication between Zeebe brokers and the Zeebe Gateway.
 
 ### Zeebe cluster configuration
 
-The following Zeebe brokers and replication configuration is supported:
+The following Zeebe brokers and replication configuration are supported:
 
 - `clusterSize` must be a multiple of **2** and at least **4** to evenly distribute brokers across the two regions.
 - `replicationFactor` must be **4** to ensure even partition distribution across regions.

docs/self-managed/connectors-deployment/connectors-configuration.md

@@ -54,8 +54,8 @@ Zeebe:
 
 | Environment variable                                | Purpose                                                                        |
 | :-------------------------------------------------- | :----------------------------------------------------------------------------- |
-| `CAMUNDA_CLIENT_ZEEBE_BASEURL` (required)           | The base URL of the Zeebe broker (HTTPS)                                       |
-| `CAMUNDA_CLIENT_ZEEBE_CACERTIFICATEPATH` (optional) | The file location of the certificate to be used to connect to the Zeebe broker |
+| `CAMUNDA_CLIENT_ZEEBE_BASEURL` (required)           | The base URL of the Zeebe Broker (HTTPS)                                       |
+| `CAMUNDA_CLIENT_ZEEBE_CACERTIFICATEPATH` (optional) | The file location of the certificate to be used to connect to the Zeebe Broker |
 
 ```bash
 ZEEBE_CLIENT_BROKER_GATEWAY-ADDRESS=127.0.0.1:26500

docs/self-managed/modeler/web-modeler/troubleshooting/troubleshoot-zeebe-connection.md

@@ -21,7 +21,7 @@ Depending on your infrastructure, the default timeouts configured may be too sho
 You can pass custom timeouts in milliseconds for Web Modeler's Zeebe client to `modeler-restapi` via three individual environment variables:
 
 ```shell
-ZEEBE_CLIENT_REQUESTTIMEOUT=30000 # limit the time to wait for a response from the Zeebe gateway
+ZEEBE_CLIENT_REQUESTTIMEOUT=30000 # limit the time to wait for a response from the Zeebe Gateway
 ZEEBE_AUTH_CONNECT_TIMEOUT=60000 # limit the time to wait for a connection to the OAuth server
 ZEEBE_AUTH_READ_TIMEOUT=60000 # limits the time to wait for a response from the OAuth server
 ```

docs/self-managed/operate-deployment/operate-configuration.md

@@ -209,9 +209,9 @@ camunda.operate:
       selfSigned: true
 ```
 
-## Zeebe broker connection
+## Zeebe Broker connection
 
-Operate needs a connection to the Zeebe broker to start the import and execute user operations.
+Operate needs a connection to the Zeebe Broker to start the import and execute user operations.
 
 ### Settings to connect
 

docs/self-managed/operational-guides/configure-flow-control/configure-flow-control.md

@@ -21,7 +21,7 @@ A static write rate limit can prevent throughput peaks, and write rate throttlin
 These write limits are enabled by default in SaaS and disabled in Self-Managed. For most use cases, write rate limits can be enabled as needed if an issue arises.
 :::
 
-Flow control is configured in your Zeebe broker's `application.yaml` file. The default values can be found in the `# flowControl` section of the Zeebe broker [configuration](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) and [standalone](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) templates.
+Flow control is configured in your Zeebe Broker's `application.yaml` file. The default values can be found in the `# flowControl` section of the Zeebe Broker [configuration](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template) and [standalone](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.standalone.yaml.template) templates.
 
 ```yaml
 zeebe:

docs/self-managed/operational-guides/multi-region/dual-region-ops.md

@@ -147,7 +147,7 @@ Start with creating a port-forward to the `Zeebe Gateway` in the surviving regio
 
 The following alternatives to port-forwarding are possible:
 
-- if Zeebe Gateway is exposed to the outside of the Kubernetes cluster, you can skip port-forwarding and use the URL directly
+- If the Zeebe Gateway is exposed to the outside of the Kubernetes cluster, you can skip port-forwarding and use the URL directly
 - [`exec`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_exec/) into an existing pod (such as Elasticsearch), and execute `curl` commands from inside of the pod
 - [`run`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_run/) an Ubuntu pod in the cluster to execute `curl` commands from inside the Kubernetes cluster
 

docs/self-managed/setup/deploy/local/local-kubernetes-cluster.md

@@ -91,7 +91,7 @@ First, port-forward each of the components. Use a separate terminal for each com
 
 ## Connecting to the workflow engine
 
-To interact with the Camunda workflow engine via Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe gateway as follows:
+To interact with the Camunda workflow engine via Zeebe Gateway using [zbctl](/apis-tools/community-clients/cli-client/cli-get-started.md) or a local client/worker from outside the Kubernetes cluster, run `kubectl port-forward` to the Zeebe Gateway as follows:
 
 ```sh
 kubectl port-forward svc/camunda-zeebe-gateway 26500:26500

docs/self-managed/setup/deploy/local/manual.md

@@ -70,7 +70,7 @@ For **Windows users**, take the following steps:
 4. Navigate to the `bin` folder.
 5. Start the broker by double-clicking on the `broker.bat` file.
 
-Once the Zeebe broker has started, it should produce the following output:
+Once the Zeebe Broker has started, it should produce the following output:
 
 ```log
 23:39:13.246 [] [main] INFO  io.camunda.zeebe.broker.system - Scheduler configuration: Threads{cpu-bound: 2, io-bound: 2}.

docs/self-managed/setup/guides/accessing-components-without-ingress.md

@@ -18,7 +18,7 @@ To interact with Camunda workflow engine via [Zeebe Gateway](/self-managed/zeebe
 kubectl port-forward svc/camunda-zeebe-gateway 26500:26500
 ```
 
-Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe broker.
+Now, you can connect and execute operations against your new Zeebe cluster. This allows you to use `zbctl` as a command line interface to read and create resources inside the Zeebe Broker.
 
 :::note
 Accessing the Zeebe cluster directly using `kubectl port-forward` is recommended for development purposes.

docs/self-managed/setup/install.md

@@ -418,5 +418,5 @@ For upgrading the Camunda Helm chart from one release to another, perform a [Hel
 
 ## General notes
 
-- **Zeebe gateway** is deployed as a stateless service. We support [Kubernetes startup and liveness probes](/self-managed/zeebe-deployment/configuration/gateway-health-probes.md) for Zeebe.
+- **Zeebe Gateway** is deployed as a stateless service. We support [Kubernetes startup and liveness probes](/self-managed/zeebe-deployment/configuration/gateway-health-probes.md) for Zeebe.
 - **Zeebe broker nodes** need to be deployed as a [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) to preserve the identity of cluster nodes. StatefulSets require persistent storage, which must be allocated in advance. Depending on your cloud provider, the persistent storage differs as it is provider-specific.

docs/self-managed/tasklist-deployment/tasklist-configuration.md

@@ -136,9 +136,9 @@ camunda.tasklist:
       selfSigned: true
 ```
 
-## Zeebe broker connection
+## Zeebe Broker connection
 
-Tasklist needs a connection to Zeebe broker to start the import.
+Tasklist needs a connection to the Zeebe Broker to start the import.
 
 ### Settings to connect
 

docs/self-managed/zeebe-deployment/configuration/broker.md

@@ -2,7 +2,7 @@
 id: broker-config
 title: "Broker configuration"
 sidebar_label: "Broker configuration"
-description: "Let's analyze how to configure the Zeebe broker"
+description: "Let's analyze how to configure the Zeebe Broker"
 ---
 
 A complete broker configuration template is available in the [Zeebe repo](https://github.com/camunda/camunda/blob/main/dist/src/main/config/broker.yaml.template).

docs/self-managed/zeebe-deployment/configuration/gateway.md

@@ -2,7 +2,7 @@
 id: gateway-config
 title: "Gateway configuration"
 sidebar_label: "Gateway configuration"
-description: "Analyze how to configure the Zeebe gateway, including byte sizes, time units, paths, and sample YAML snippets."
+description: "Analyze how to configure the Zeebe Gateway, including byte sizes, time units, paths, and sample YAML snippets."
 ---
 
 The Zeebe Gateway can be configured similarly to the broker via the `application.yaml` file or environment variables. A complete gateway configuration template is available in the [Zeebe repository](https://github.com/camunda/camunda/blob/main/dist/src/main/config/gateway.yaml.template).