> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cache Component

> Cache Component (Cache Component), the component in the Apinizer platform that provides caching functions to improve API Gateway performance. It reduces API Gateway's response time and lightens backend load by keeping frequently used data and configurations in memory. It provides two types of cache support: Local Cache and Distributed Cache (Hazelcast). Data such as throttling and quota are stored in distributed cache. Response cache can be both local and distributed; when local, Hazelcast is not used.

## Cache Component Concept

<CardGroup cols={2}>
  <Card title="Performance Improvement" icon="gauge">
    Reduces response time
  </Card>

  <Card title="Backend Load" icon="server">
    Lightens backend load
  </Card>

  <Card title="High Availability" icon="heart-pulse">
    Protection against backend errors
  </Card>

  <Card title="Cost Savings" icon="dollar-sign">
    Reduces backend resource usage
  </Card>
</CardGroup>

## Cache Component Types

### Local Cache

<AccordionGroup>
  <Accordion title="Configuration Cache">
    * API Proxy configurations
    * Policy definitions
    * Routing information
    * Metadata information
  </Accordion>

  <Accordion title="Token Cache">
    * OAuth2/JWT tokens
    * Token validation results
    * User session information
  </Accordion>

  <Accordion title="Response Cache">
    * API responses
    * Cache key-based storage
    * TTL (Time To Live) management
    * Can be configured as local or distributed

    <Tip>
      When response cache is configured as local, Hazelcast is not used. When configured as distributed, Hazelcast is used and shared among all API Gateway instances.
    </Tip>
  </Accordion>
</AccordionGroup>

### Distributed Cache (Hazelcast)

<CardGroup cols={2}>
  <Card title="Hazelcast" icon="network-wired">
    Distributed cache infrastructure

    * Multi-node support
    * High availability
    * Management and monitoring can be done in Apinizer
    * Can run in independent namespaces from Gateway pods
  </Card>

  <Card title="Shared State" icon="users">
    Data such as throttling and quota are stored distributed

    * Throttling data
    * Quota data
    * Shared state information
    * Cross-namespace access support
  </Card>

  <Card title="Response Cache" icon="arrows-rotate">
    Response cache can be both local and distributed

    * Local response cache: Hazelcast is not used
    * Distributed response cache: Hazelcast is used
  </Card>

  <Card title="Cache Invalidation" icon="arrows-rotate">
    Automatic and event-based invalidation

    * Automatic invalidation
    * Event-based invalidation
    * Pattern-based invalidation
  </Card>
</CardGroup>

<Info>
  Hazelcast is managed and can be monitored by Apinizer. When distributed cache is used, data such as throttling and quota are shared among all API Gateway instances.

  **Namespace Independence:**

  Cache Server pods can now run in different Kubernetes namespaces than Gateway pods. Gateway pods can access cache servers in other namespaces using Kubernetes service discovery (e.g., `http://cache-http-service.apinizer-cache.svc.cluster.local:8090`). This provides more flexible infrastructure management and allows you to separate Gateway and Cache workloads. For Cache Server configuration, see the [Distributed Cache](/en/admin/server-management/distributed-cache) page.
</Info>

## Cache Strategies

<CardGroup cols={3}>
  <Card title="Cache-Aside (Lazy Loading)" icon="search">
    1. Search in cache
    2. If not found, get from backend
    3. Save to cache
    4. Return to client
  </Card>

  <Card title="Write-Through" icon="arrow-right">
    1. Write to backend
    2. Write to cache
    3. Return to client
  </Card>

  <Card title="Write-Back (Write-Behind)" icon="clock">
    1. Write to cache
    2. Return to client
    3. Write to backend asynchronously
  </Card>
</CardGroup>

## Cache Configuration

### Cache Key Strategy

<CardGroup cols={2}>
  <Card title="URL Based" icon="link">
    URL path is used as cache key

    Example: `GET /api/v1/products` → Cache Key: `/api/v1/products`
  </Card>

  <Card title="Query Parameter" icon="code">
    URL and query parameters are included in cache key

    Example: `GET /api/v1/products?category=electronics` → Cache Key: `/api/v1/products?category=electronics`
  </Card>

  <Card title="Header Based" icon="file-lines">
    URL and specific header values are included in cache key

    Cache Key: URL + Header values
  </Card>

  <Card title="Custom Key" icon="key">
    Creating custom cache key

    User-defined cache key strategies can be used.
  </Card>
</CardGroup>

### Cache TTL (Time To Live)

<AccordionGroup>
  <Accordion title="Fixed TTL">
    * Keeping in cache for a specific period
    * Example: 5 minutes, 1 hour
  </Accordion>

  <Accordion title="Dynamic TTL">
    * TTL based on response headers
    * Cache-Control header
    * Expires header
  </Accordion>

  <Accordion title="Conditional TTL">
    * Conditional TTL
    * Based on response status code
    * Based on content type
  </Accordion>
</AccordionGroup>

## Cache Invalidation

<CardGroup cols={2}>
  <Card title="TTL Expiry" icon="clock">
    * Automatic deletion with timeout
  </Card>

  <Card title="Manual Invalidation" icon="trash">
    * Manual cache clearing
    * Invalidation via API
  </Card>

  <Card title="Event-Based" icon="bell">
    * Event-based invalidation
    * Invalidation with webhook
  </Card>

  <Card title="Pattern-Based" icon="filter">
    * Pattern-based invalidation
    * Wildcard invalidation
  </Card>
</CardGroup>

## Cache Usage Scenarios

<CardGroup cols={3}>
  <Card title="Response Caching" icon="arrows-rotate">
    1. First request: Get from backend, save to cache
    2. Subsequent requests: Return from cache
    3. After TTL: Clear cache, get from backend again
  </Card>

  <Card title="Token Caching" icon="key">
    1. Token validation: Check if token exists in cache
    2. If in cache: Return without validation
    3. If not in cache: Validate from Identity Manager, save to cache
  </Card>

  <Card title="Configuration Caching" icon="gear">
    1. API Proxy configuration: Get from Management API
    2. Save to local cache
    3. On configuration change: Invalidate cache
  </Card>

  <Card title="Throttling and Quota" icon="gauge">
    1. Throttling and quota data are stored in distributed cache
    2. Shared among all API Gateway instances (even if in different namespaces)
    3. Synchronized via Hazelcast
    4. Gateway pods access cache servers in different namespaces via Kubernetes service discovery
  </Card>
</CardGroup>

## Cache Best Practices

<CardGroup cols={2}>
  <Card title="TTL Management" icon="clock">
    * Select appropriate TTL values
    * Too short TTL reduces performance
    * Too long TTL risks stale data
  </Card>

  <Card title="Cache Key Design" icon="key">
    * Meaningful cache keys
    * Prevent collisions
    * Pattern-based invalidation
  </Card>

  <Card title="Memory Management" icon="memory">
    * Cache size limits
    * Eviction policies
    * Memory monitoring
  </Card>

  <Card title="Error Handling" icon="triangle-exclamation">
    * Fallback on cache errors
    * Routing to backend
    * Error logging
  </Card>
</CardGroup>

## Next Steps

<CardGroup cols={2}>
  <Card title="Data Log Layer" icon="database" href="/en/concepts/architecture#5-data-and-log-layer">
    Learn about Data Log Layer architecture
  </Card>

  <Card title="API Gateway" icon="shield" href="/en/concepts/core-components/api-gateway">
    Learn about API Gateway component
  </Card>
</CardGroup>