← All Case Studies
Architecture Case Study 03 · Badge Calculation
🏷️ Badge Calculation Pipeline
How Badges-Trending-Calculator computes trending scores and feeds the badges UI — the platform's most isolated, lowest-risk subsystem with zero coupling to the checkout or pricing critical paths.
Badges-Trending-CalculatorbadgesEDW
📖
Overview
The badges subsystem is deliberately isolated. Badges-Trending-Calculator computes trending scores from EDW data and feeds badges (the UI display layer). Neither service has runtime coupling to checkout, pricing, or incentive flows — making this the safest-to-deploy subsystem on the platform.
⚙️
Badge Score Computation Pipeline
Fully offline computation — no synchronous dependencies on Tier-1 services.
1
EDW / BigQuery
Historical deal performance data · view counts · purchase signals
batch
→
2
Score Computation
Badges-Trending-Calculator · trending algorithm · rank normalization
scheduled
→
3
Score Storage
trending_score table · BigQuery write · per-deal rank
batch
→
4
Badge Display
badges UI · reads score API · renders trending chip on deal card
<5ms
→
5
Cache Layer
Redis or CDN cache · badge scores change infrequently · TTL 1hr
<1ms
✅
Zero coupling to checkout or pricing critical paths — safe independent deployment
Neither badges nor Badges-Trending-Calculator is called synchronously by any Tier-1 or Tier-2 service. Score computation failures cause stale badge display — not pricing errors or order failures. Blast radius: display-only.
🔗
Architectural Assessment
✅
Lowest blast radius of all 10 repositories — fully isolated subsystem
Graph analysis confirms zero runtime coupling to checkout, pricing, incentive, or subscription flows. Badges-Trending-Calculator is a pure batch computation service. It can be deployed, rolled back, or taken offline with no downstream impact on revenue flows.
📊
Score staleness is the only production risk — managed by TTL cache
If Badges-Trending-Calculator misses a scheduled run, deal cards display stale trending badges. This is a UX degradation, not a revenue impact. The 1-hour TTL cache provides adequate staleness tolerance for the use case.
💡
Opportunity: extend badge signal to incentive-service for personalised badges
Graph analysis shows badges currently reads only from EDW (historical data). An enhancement would be to consume incentive-service qualification signals to show personalised "deal matches your profile" badges — requires adding a Kafka consumer, low complexity.
✅
Safest deployment target in the platform — zero cross-service coordination needed
Unlike dynamic_pricing (6+ teams to coordinate) or incentive-service (4 consumers to notify), badges and Badges-Trending-Calculator can be deployed by a single engineer with zero cross-team communication required.
💡
Opportunity: badges subsystem is the ideal candidate for experimental features
The complete isolation of the badges subsystem makes it an ideal target for A/B testing new badge types, experimenting with new score algorithms, or piloting new ML-powered ranking without any risk to platform critical paths.
🎯
Key Takeaway
The badges pipeline is the healthiest architectural pattern in the platform — offline computation, pure batch, zero synchronous dependencies. It demonstrates the right way to build analytics-driven UI features. The only enhancement opportunity is extending it to consume incentive-service personalisation signals via Kafka, which would require only a single Kafka consumer addition.