# Logical Region Routing Configuration Example
# This demonstrates how to configure logical region routing using ApplicationID
# instead of ClusterID for the observability system.

apiVersion: v1
kind: ConfigMap
metadata:
  name: observability
  namespace: observability
data:
  config.json: |
    {
      "vendors": {
        "aws": [
          {
            "region": "us-west-1",
            "routers": [
              {
                "dnsAddress": "http://us-west-1-logical-1.example.com",
                "primary": true,
                "logicalRegionName": "logical-region-1"
              },
              {
                "dnsAddress": "http://us-west-1-logical-2.example.com",
                "primary": false,
                "logicalRegionName": "logical-region-2"
              }
            ]
          },
          {
            "region": "us-east-1",
            "routers": [
              {
                "dnsAddress": "http://us-east-1-logical-1.example.com",
                "primary": true,
                "logicalRegionName": "logical-region-1"
              },
              {
                "dnsAddress": "http://us-east-1-logical-2.example.com",
                "primary": false,
                "logicalRegionName": "logical-region-2"
              }
            ]
          }
        ]
      },
      "routes": {
        "us-west-1": {
          "byoc:1372813089209216864:*": "logical-region-1",
          "dedicated:1372813089209216865:*": "logical-region-2",
          "serverless:*:*": "logical-region-2",
          "dedicated:*:app-123": "logical-region-1",
          "dedicated:*:app-456": "logical-region-2",
          "*:*:*": "logical-region-1"
        },
        "us-east-1": {
          "dedicated:1372813089209216864:*": "logical-region-1",
          "serverless:*:*": "logical-region-2",
          "dedicated:*:app-789": "logical-region-2",
          "*:*:*": "logical-region-1"
        }
      }
    }

---

# Additional ConfigMaps for distributed route tables
# When dealing with large numbers of tenants (1M+), routes can be split
# across multiple ConfigMaps due to the 1MiB Kubernetes limit

apiVersion: v1
kind: ConfigMap
metadata:
  name: observability-routes-1
  namespace: observability
data:
  routes.json: |
    {
      "us-west-1": {
        "dedicated:tenant-001:app-web": "logical-region-1",
        "dedicated:tenant-002:app-api": "logical-region-2",
        "dedicated:tenant-003:app-worker": "logical-region-1",
        "serverless:tenant-004:app-lambda": "logical-region-2"
      }
    }

---

apiVersion: v1
kind: ConfigMap
metadata:
  name: observability-routes-2
  namespace: observability
data:
  routes.json: |
    {
      "us-west-1": {
        "dedicated:tenant-005:app-mobile": "logical-region-1",
        "dedicated:tenant-006:app-analytics": "logical-region-2",
        "serverless:tenant-007:app-streaming": "logical-region-1"
      }
    }

---

# Routing Pattern Examples:
#
# 1. **Exact Application Matching**:
#    - "dedicated:1372813089209216864:app-123" → "logical-region-1"
#    - Routes specific tenant + application combination to logical region
#
# 2. **Tenant-level Routing** (any application):
#    - "dedicated:1372813089209216864:*" → "logical-region-1"
#    - All applications for this tenant go to same logical region
#
# 3. **Business Type Routing**:
#    - "serverless:*:*" → "logical-region-2"
#    - All serverless workloads regardless of tenant/application
#
# 4. **Application-specific Routing**:
#    - "dedicated:*:app-123" → "logical-region-1"
#    - Specific application across all tenants
#
# 5. **Fallback Routing**:
#    - "*:*:*" → "logical-region-1"
#    - Default route for unmatched patterns
#
# **Matching Priority** (uses longest/most specific match):
# 1. exact:tenant:application (highest priority)
# 2. exact:tenant:*
# 3. exact:*:application
# 4. exact:*:*
# 5. *:*:* (lowest priority, fallback)