MONOLITH TO MICROSERVICES: PAYMENT SYSTEM DECOMPOSITION

DOMAIN-DRIVEN DESIGN (Bounded contexts)

Context 1: PAYMENT PROCESSING
→ Responsibility: Charge card, handle PCI compliance
→ API: POST /charges, GET /charges/{id}, POST /charges/{id}/refund
→ Database: payment_db (Stripe keys encrypted)
→ Dependencies: None (single source of truth)
→ Deployment: On-demand, 99.99% SLA

Context 2: BILLING & INVOICING
→ Responsibility: Calculate amounts, generate invoices, track payment history
→ API: POST /invoices, GET /invoices/{id}, PUT /invoices/{id}/status
→ Database: billing_db (separate DB, replicated daily from payment service)
→ Dependencies: Subscribes to payment-processed events
→ Deployment: Batch process, handles 10K invoices/day

Context 3: SUBSCRIPTION MANAGEMENT
→ Responsibility: Create plans, manage renewals, handle cancellations
→ API: POST /subscriptions, PUT /subscriptions/{id}, DELETE /subscriptions/{id}
→ Database: subscription_db
→ Dependencies: Publishes subscription.created, subscription.cancelled events
→ Deployment: On-demand, handles scaling during renewal cycles

COMMUNICATION STRATEGY
→ Synchronous (REST): Subscription → Billing (verify amount before charging)
→ Asynchronous (Event sourcing): Payment service publishes payment.succeeded event
→ Billing service subscribes, generates invoice, publishes invoice.created event
→ Audit trail: Every event stored in event-log table with timestamp + metadata

SAGA PATTERN: Subscription Renewal Flow
1. Subscription service triggers renewal (via cron)
2. Publishes: subscription.renewal-started event
3. Billing service: Calculates amount, publishes billing.amount-calculated
4. Payment service: Attempts charge, publishes payment.succeeded OR payment.failed
5. If failed: Subscription service publishes subscription.renewal-failed
6. If succeeded: Subscription service publishes subscription.renewed
→ Compensation: Refund endpoint in payment service (rollback on failure)

DATABASE STRATEGY
→ Payment DB: Postgres (ACID, PCI compliance, encrypted)
→ Billing DB: Read-replica from payment DB (eventual consistency)
→ Subscription DB: Separate Postgres (customer-scoped sharding)
→ Cross-service queries: Use event-log for auditing, not direct DB access

SERVICE MESH (observability)
→ Istio for traffic management
→ Distributed tracing: Every request tagged with correlation_id
→ Alert on: Circuit breaker opens (cascading failures), event lag > 30 seconds

PHASED ROLLOUT
Phase 1 (Weeks 1-2): Deploy payment service independently, dual-write to old + new DB
Phase 2 (Weeks 3-4): Route 20% traffic to new payment service, monitor errors
Phase 3 (Weeks 5-6): Cutover to 100%, keep old monolith running for 2-week rollback window
Phase 4 (Week 7+): Extract billing and subscription services (same pattern)

RISK MITIGATION
→ Cascade failure: Implement bulkheads (timeout 3sec, retry 2x, circuit breaker after 5 failures)
→ Data inconsistency: Ensure idempotency (unique request IDs prevent duplicate charges)
→ Monitoring: Alert if payment-processed lag > 5 minutes