← All Case Studies
Architecture Case Study 02 · Subscription Flow
🔄 Subscription Discount Lifecycle
How subscription-programs-app gates membership activation on incentive eligibility, KillBill plan enrollment, and discount calculation — and why an incentive-service outage blocks subscription revenue.
subscription-programs-appincentive-serviceKillBilldynamic_pricingorders-service
📖
Overview
subscription-programs-app manages the full membership lifecycle — from plan selection through KillBill billing to incentive activation. The critical insight from graph analysis: the service's largest community (78 nodes, community #0) is entirely dedicated to calling incentive-service, making it an implicit Tier-1 dependency.
⚙️
Membership Activation Pipeline — 6 Stages
Pipeline pattern — failure at any step triggers full rollback.
1
Plan Selection
User selects membership plan · SelectProgramService · SelectResource
<5ms
→
2
Eligibility Check
incentive-service /incentive/get · EligibilityEval · constraint check
10–35ms
→
3
KillBill Subscribe
KbSubscriptionCreateStep · KillBill API · account create/update
20–60ms
→
4
Payment Capture
GPS payment processing · cybersource/adyen/paypal routing
100–300ms
→
5
Activate Incentives
ActivateIncentivesStep → incentive-service /incentive/use
10–25ms
→
6
Confirmation
mBus event publish · email trigger → message-service
async
💣
incentive-service outage directly blocks subscription membership activation
Steps 2 and 5 both call incentive-service synchronously. An incentive-service degradation blocks new membership enrollments — converting a pricing service issue into a subscription revenue impact. No circuit breaker exists on either call.
🔗
Discount Calculation Logic
🧮
Discount = IncentiveEvaluationOperation + KillBill plan tier + ML min-price floor
The final subscription discount is the intersection of: (1) incentive-service constraint evaluation (campaign eligibility, user cap, force-incentive flag), (2) KillBill plan discount tier, and (3) dynamic_pricing min-price floor from ML Toolkit. All three must agree.
🔄
Membership god-object (degree 197) bridges 30+ communities — highest structural risk
Membership class in subscription-programs-app has betweenness centrality 0.137 and connects KillBill, Business Metrics, Subscription Plans, and 30+ other communities. Any schema change propagates breakage platform-wide with zero isolation.
🔁
Rollback pipeline on payment failure re-enters incentive-service
Payment failure triggers CancelIncentivesStep which calls incentive-service /incentive/unuse. Under incentive-service degradation, both the forward path and the rollback path are blocked — leaving subscriptions in an inconsistent state.
🔴
subscription-programs-app community #0 (78 nodes) is entirely incentive-service calls
The strongest cross-service coupling signal in the platform graph. This community contains ActivateIncentivesStep, CancelIncentivesStep, KbSubscriptionCreateStep, and all their dependencies — all routing through incentive-service.
⚠️
No circuit breaker on either incentive-service call in the activation pipeline
Both eligibility check (step 2) and incentive activation (step 5) call incentive-service synchronously without a Resilience4j circuit breaker. Recommend adding a 30ms timeout + cached fallback to both.
🎯
Key Takeaway
subscription discounts are calculated across 3 services with no circuit breaker protection. The Membership god-object is the highest structural risk — degree 197 with 0.137 betweenness means any Membership change has platform-wide blast radius. Priority: (1) add circuit breaker to ActivateIncentivesStep, (2) decompose Membership into SubscriptionStatus + BillingRecord + IncentiveActivationState.