Skip to main content

Step 2: Customer Tier Priority Routing

Severity is a good starting point, but in a multi-tenant system, you often want to provide better service to paying customers. In this step, you will enhance the priority calculation from Step 1 to also consider the customer's subscription tier.

The Goal​

You will modify the mapping processor to create a more sophisticated priority_score. This score will be a combination of the event's severity and the customer's tier, ensuring that a WARN from an enterprise customer is treated as higher priority than a WARN from a free tier user.

The output section will remain unchanged, as it already routes based on the final priority field.

Implementation​

  1. Start with the Previous Pipeline: Copy the severity-router.yaml file you created in Step 1 to a new file named tier-router.yaml.

    cp severity-router.yaml tier-router.yaml

  2. Enhance the Classification Processor: Open tier-router.yaml. Find the mapping processor that calculates the priority. You are going to replace it with a more sophisticated version that incorporates a tier_multiplier.

    Replace the classification processor in tier-router.yaml
    # This replaces the second 'mapping' processor from Step 1
    - mapping: |
        root = this
        root.severity = this.severity.string().uppercase()
        root.customer_tier = this.customer_tier.or("free").string().lowercase()

        # 1. Calculate a base score from severity
        let severity_score = match root.severity {
          "CRITICAL" | "FATAL" => 80,
          "ERROR" => 60,
          "WARN" | "WARNING" => 40,
          _ => 20
        }

        # 2. Determine a multiplier based on customer tier
        let tier_multiplier = match root.customer_tier {
          "enterprise" => 2.0,
          "premium" => 1.5,
          _ => 1.0
        }

        # 3. Calculate the final score
        root.priority_score = severity_score * tier_multiplier

        # 4. Map the final score to a priority level
        root.priority = match {
          root.priority_score >= 100 => "critical",
          root.priority_score >= 80 => "high",
          root.priority_score >= 40 => "normal",
          _ => "low"
        }

3. Deploy and Test​

Deploy the new pipeline and send events with different combinations of severity and customer tier.

# Test an ERROR from a 'free' user (score: 60 * 1.0 = 60 => high priority)
curl -X POST http://localhost:8080/logs -H "Content-Type: application/json" \
  -d '{"severity": "ERROR", "customer_tier": "free", "message": "Login failed"}'

# Test a WARN from an 'enterprise' user (score: 40 * 2.0 = 80 => high priority)
curl -X POST http://localhost:8080/logs -H "Content-Type: application/json" \
  -d '{"severity": "WARN", "customer_tier": "enterprise", "message": "API latency degradation"}'

4. Verify​

Check your Kafka topics. You will see that even though the second event was only a WARN, it was routed to the logs-high topic because it came from an enterprise customer, demonstrating that your enhanced logic is working.

You have now built a priority routing system that can make more intelligent, business-aware decisions.