databroker: rename cache service (#1790)

* rename cache folder

* rename cache service everywhere

* skip yaml in examples

* Update docs/docs/topics/data-storage.md

Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com>

Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com>

docs/docs/architecture.md

@@ -29,13 +29,13 @@ Pomerium is composed of 4 logical components:
   - Handles authentication flow to your IdP as needed
   - Handles identity verification after initial Authentication
   - Establishes user session cookie
-  - Stores user OIDC tokens in cache service
+  - Stores user OIDC tokens in databroker service
 - Authorization Service
   - Processes policy to determine permissions for each service
   - Handles authorization check for all user sessions
   - Directs Proxy service to initiate Authentication flow as required
   - Provides additional security releated headers for upstream services to consume
-- Cache Service
+- Data Broker Service
   - Retrieves identity provider related data such as group membership
   - Stores and refreshes identity provider access and refresh tokens
   - Provides streaming authoritative session and identity data to Authorize service

docs/docs/topics/data-storage.md

@@ -19,11 +19,11 @@ Pomerium keeps persistent state out of most components, but an identity-aware ac
 - Group membership was fixed from session creation
 - Slow initial authentication flow to fetch user data
 
-To address these limitations, the Pomerium `cache` service runs a number of internal services responsible for maintaining data and state.
+To address these limitations, the Pomerium `databroker` service runs a number of internal services responsible for maintaining data and state.
 
 #### Design
 
-Internal to the `cache` service, the `databroker` is responsible for providing a stateful storage layer.  Services which require high performance maintain a streaming local cache of the contents of the `databroker`, while others may call `databroker` in real time.  Only the `databroker` is expected to maintain authoritative state.
+The `databroker` is responsible for providing a stateful storage layer.  Services which require high performance maintain a streaming local cache of the contents of the `databroker`, while others may call `databroker` in real time.  Only the `databroker` is expected to maintain authoritative state.
 
 
 ## Persistence
@@ -33,27 +33,27 @@ To prevent early session loss in production deployments, persistent storage back
 
 ## Backends
 
-Configuration options for each backend are detailed in [cache configuration reference](/reference/#cache-service).
+Configuration options for each backend are detailed in [databroker configuration reference](/reference/#databroker-service).
 
 In all backends, Pomerium encrypts record values.  This ensures security of all records at rest, regardless of data store capabilities.  While this prevents many classes of attack vector, additional security measures should always be taken to secure data in transit and minimize access to the backends themselves.
 
 Please see Pomerium backend and upstream storage system documentation for best practices.
 
 ### In-Memory
-- Cache Service HA: `no`
+- Data Broker Service HA: `no`
 - Data Store HA: `no`
 - Data Persistence: `no`
 
 The default storage backend for `databroker` is memory based.  This backend provides
-easy deployment semantics but is not persistent or highly available.  Running more than one `cache` instance configured for memory backed storage is not supported and will lead to non-deterministic behavior.
+easy deployment semantics but is not persistent or highly available.  Running more than one `databroker` instance configured for memory backed storage is not supported and will lead to non-deterministic behavior.
 
 ### Redis
 
-- Cache Service HA: `yes`
+- Data Broker Service HA: `yes`
 - Data Store HA: `yes`
 - Data Persistence: `yes`
 
-The Redis based backend supports multiple `cache` instances and persistence across restarts.  We recommend a dedicated redis instance for Pomerium to provide the strongest security and performance guarantees.
+The Redis based backend supports multiple `databroker` instances and persistence across restarts.  We recommend a dedicated redis instance for Pomerium to provide the strongest security and performance guarantees.
 
 #### High Availability
 Redis should be configured to provide high availability via [replication](https://redis.io/topics/replication) and failover.  Sentinal and cluster are not supported at this time.

docs/docs/topics/production-deployment.md

@@ -28,7 +28,7 @@ In dedicated service mode, you have the opportunity to scale the components of P
 
 All of Pomerium's components are designed to be stateless, and may all be scaled horizontally or vertically. In general, horizontal scaling is recommended.  Vertical scaling will lead to diminished returns after ~8 vCPUs.
 
-The Cache service, which is responsible for session and identity related data, must be [configured for external persistence](/docs/topics/data-storage.md) to be fully stateless.
+The Data Broker service, which is responsible for session and identity related data, must be [configured for external persistence](/docs/topics/data-storage.md) to be fully stateless.
 
 ### Proxy
 
@@ -44,18 +44,18 @@ Authorize will need resources scaled in conjunction with request count. Request
 
 ### Authenticate
 
-The Authenticate service handles session cookie setup, session storage, and authentication with your Identity Provider. 
+The Authenticate service handles session cookie setup, session storage, and authentication with your Identity Provider.
 
 Authenticate requires significantly fewer resources than other components due to the only-occasional requirement to establish new sessions.  Add resources to the Authenticate service if you have a high session/user churn rate. The requests should be constant time and complexity, but may vary by Identity Provider implementation.
 
-### Cache
+### Data Broker
 
-The Cache service is responsible for background identity data retrieval and storage.  It is in the hot path for user authentication.  However, it does not directly handle user traffic and is not in-path for authorization decisions.
+The Data Broker service is responsible for background identity data retrieval and storage.  It is in the hot path for user authentication.  However, it does not directly handle user traffic and is not in-path for authorization decisions.
 
-The Cache service does not require significant resources, as it provides streaming updates of state changes to the Authorize service.  There will be utilization spikes when Authorize services are restarted and perform an initial synchronization.  Add resources if running many Authorize services and performing restarts in large batches.  In many deployments, 2 replicas of Cache is enough to provide resilient service.
+The Data Broker service does not require significant resources, as it provides streaming updates of state changes to the Authorize service.  There will be utilization spikes when Authorize services are restarted and perform an initial synchronization.  Add resources if running many Authorize services and performing restarts in large batches.  In many deployments, 2 replicas of Data Broker is enough to provide resilient service.
 
 ::: warning
-In a production configuration, Cache CPU/IO utilization also translates to IO load on the [underlying storage system](/docs/topics/data-storage.md).  Ensure it is scaled accordingly!
+In a production configuration, Data Broker CPU/IO utilization also translates to IO load on the [underlying storage system](/docs/topics/data-storage.md).  Ensure it is scaled accordingly!
 :::
 
 ## Load Balancing
@@ -74,11 +74,11 @@ You should provide a TCP or HTTP(s) load balancer between end users and the Auth
 
 Authenticate is compatible with any L4 or L7/HTTP load balancer. Session stickiness should not be required and it is typical to have Authenticate be a named vhost on the same L7 load balancer as the Proxy service.
 
-### Authorize and Cache
+### Authorize and Data Broker
 
-You do **not** need to provide a load balancer in front of Authorize and Cache services. Both utilize GRPC, and thus has special requirements if you should choose to use an external load balancer. GRPC can perform client based load balancing, and in most configurations is the best architecture.
+You do **not** need to provide a load balancer in front of Authorize and Data Broker services. Both utilize GRPC, and thus has special requirements if you should choose to use an external load balancer. GRPC can perform client based load balancing, and in most configurations is the best architecture.
 
-By default, Pomerium gRPC clients will automatically connect to all IPs returned by a DNS query for the name of an upstream service. They will then regularly re-query DNS for changes to the Authorize or Cache service cluster. Health checks and failover are automatic.
+By default, Pomerium gRPC clients will automatically connect to all IPs returned by a DNS query for the name of an upstream service. They will then regularly re-query DNS for changes to the Authorize or Data Broker service cluster. Health checks and failover are automatic.
 
 **Many load balancers do not support HTTP2 yet. Please verify with your hardware, software or cloud provider**
 
@@ -99,8 +99,8 @@ Regardless of the service mode, it is recommended you run 2+ instances of Pomeri
 Ensure that you have enough spare capacity to handle the scope of your failure domains.
 
 ::: warning
-Multiple replicas of Cache or all-in-one service are only supported with [external storage](/docs/topics/data-storage.md) configured
-::: 
+Multiple replicas of Data Broker or all-in-one service are only supported with [external storage](/docs/topics/data-storage.md) configured
+:::
 
 ## SSL/TLS Certificates