Step 3: Multi-Criteria Priority Scoring

So far, you've routed events based on severity and customer tier. Now, you will make the logic even smarter by adding a third criterion: the business importance of the event itself.

The Goal

You will modify the mapping processor to add an event_type_score to the final priority_score. This ensures that a financially significant event like payment.failed is treated as higher priority than a routine event like user.login, even if they have the same severity and customer tier.

Implementation

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

   cp tier-router.yaml multi-criteria-router.yaml

2. Enhance the Classification Processor: Open multi-criteria-router.yaml. You will modify the mapping processor to include the new event_type_score.

   Replace the classification processor in multi-criteria-router.yaml

   # This replaces the mapping processor from Step 2
   - mapping: |
       root = this
       root.severity = this.severity.string().uppercase()
       root.customer_tier = this.customer_tier.or("free").string().lowercase()
       root.event_type = this.event_type.or("unknown").string().lowercase()
   
       # 1. Calculate severity score
       let severity_score = match root.severity {
         "CRITICAL" | "FATAL" => 80,
         "ERROR" => 60,
         "WARN" | "WARNING" => 40,
         _ => 20
       }
   
       # 2. Determine tier multiplier
       let tier_multiplier = match root.customer_tier {
         "enterprise" => 2.0,
         "premium" => 1.5,
         _ => 1.0
       }
   
       # 3. Add a bonus score based on event type (NEW)
       let event_type_score = match {
         root.event_type.has_prefix("payment.") => 30,
         root.event_type.has_prefix("auth.") => 20,
         _ => 0
       }
   
       # 4. Calculate the final score
       root.priority_score = (severity_score * tier_multiplier) + event_type_score
   
       # 5. 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 that test the new logic.

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

# Test a 'WARN' from an 'enterprise' user for a PAYMENT event
# (score: 40 * 2.0 + 30 = 110 => critical)
curl -X POST http://localhost:8080/logs -H "Content-Type: application/json" \
  -d '{"severity": "WARN", "customer_tier": "enterprise", "event_type": "payment.chargeback"}'

4. Verify

Check your Kafka topics. The first WARN goes to the logs-high topic. However, the second WARN is escalated to the logs-critical topic because the scoring logic recognized it was a payment event and added a significant bonus, pushing its final score over the "critical" threshold.

You have now built a routing system that makes sophisticated, business-aware decisions by combining multiple criteria.