Technical Deep Dives

Key design decisions

-- cursor-based pagination
SELECT date
FROM expenses_2023 USE INDEX (date_index)
WHERE date > :lastDate
ORDER BY date ASC, transaction_id ASC
LIMIT :batchSize;

const upperBound = result[result.length - 1]?.date;
if (upperBound === lastDate) {
  throw new Error('Cursor stagnation detected – aborting to prevent infinite loop');
}

INSERT IGNORE INTO expenses_combined_archive (...)
SELECT ...
FROM expenses_2022
WHERE date > :lastDate AND date <= :upperBound
ORDER BY date ASC, transaction_id ASC;

if (avgRowsPerSecond < 1000) {
  batchSize = Math.max(batchSize * 0.7, MIN_BATCH_SIZE);
} else if (avgRowsPerSecond > 3000) {
  batchSize = Math.min(batchSize * 1.5, MAX_BATCH_SIZE);
}

async function executeWithRetry<T>(operation: () => Promise<T>): Promise<T> {
  for (let attempt = 0; attempt < 3; attempt++) {
    try {
      return await db.transaction(async (tx) => {
        await tx.query('SET innodb_lock_wait_timeout = 5');
        return await operation();
      });
    } catch (error) {
      if (isLockError(error) && attempt < 2) {
        await sleep(100 * (attempt + 1));
        continue;
      }
      throw error;
    }
  }
  throw new Error('Max retries exceeded');
}

if (cpu > MAX_CPU || memoryMB > MAX_MEMORY || errorRate > MAX_ERROR_RATE) {
  saveResumeState();
  flushFileOperations();
  process.exit(130); // safe, resumable shutdown
}

fs.writeFileSync(tempFile, JSON.stringify(state));
fs.renameSync(tempFile, resumeStateFile);

CREATE INDEX idx_expenses_user_date ON expenses_archive(user_id, date);
SELECT SLEEP(60);

Overview

I designed and executed a zero-downtime migration to move active subscribers from legacy Stripe price IDs to new plans in production. Because billing changes are irreversible and high-risk, the migration was built as a self-guarding operational system, not a one-off script.

The result was a controlled rollout that preserved billing continuity, respected coupon contracts, and produced auditable reconciliation artifacts before and after execution.

Problem

Legacy Stripe prices were still attached to live subscriptions while new pricing had already shipped across application code and infrastructure. Migrating these subscribers required handling:

• Stripe rate limits and transient API failures
• Subscriptions changing state mid-migration
• Contractual coupon constraints
• The risk of operator error in production environments

A naive migration risked incorrect charges, broken subscriptions, or silent data drift.

Solution

I implemented a migration pipeline with safety and observability designed in from the start.

Preflight safety gates

The script blocks execution unless all prerequisites are verified: correct environment, deployed infra (Terraform + Kubernetes), valid price mappings, and required database records.

Rate-limited, retry-safe Stripe updates

All Stripe writes are serialized, throttled well below account limits, wrapped in timeouts, and retried with exponential backoff.

const stripeUpdateQueue = new PQueue({
  concurrency: 1,
  intervalCap: 1,
  interval: 80
});

Billing-safe updates

Subscriptions are migrated using item-level updates with proration_behavior: 'none', ensuring no surprise charges and safe re-runs.

Explicit coupon policy handling

Coupons are treated as first-class constraints:

• A specific referral coupon is allowed and migrated
• All other coupons are intentionally skipped, logged, and tracked

Deterministic reconciliation

Before and after the migration, the script produces:

• Stripe subscription counts by status
• Database subscription counts by status
• An intersection view to surface mismatches between systems

Operational traceability

Each run emits per-plan logs, a master summary, structured failure breakdowns, and analytics events for post-migration monitoring.

Outcome

• Migrated legacy subscriptions with zero downtime or billing regressions
• Prevented production execution unless infra and configuration were correct
• Generated auditable reconciliation artifacts and follow-up workflows
• Established a repeatable pattern for future Stripe plan migrations

Why this matters

Billing migrations fail most often due to hidden state, operator error, or lack of observability. This project demonstrates how to treat high-risk data changes as controlled production operations—with guardrails, proofs, and clear exit paths.

Context

Product redesigned our churn experience to move beyond a simple cancellation survey and introduce reason-based retention paths. Implementing this safely was non-trivial. Churn touches billing, refunds, lifecycle state, analytics, and user messaging, and mistakes here are costly.

My role was to implement the product-designed flow end to end, ensuring correctness across Stripe, backend state, and analytics.

What I implemented

I implemented a reason-driven churn funnel backed by centralized cancellation logic.

My scope included:

• Translating product designs into a deterministic frontend flow
• Enforcing eligibility rules to prevent invalid retention offers
• Centralizing cancellation behavior to avoid Stripe and database drift
• Ensuring analytics and lifecycle state remained consistent

Frontend implementation

State and analytics

I implemented centralized state to track:

• Selected churn reason and feedback
• Submission and loading state
• Retention versus cancellation outcomes

Analytics are emitted at each step, enabling clean churn and retention funnels without backend inference.

Backend: cancellation as infrastructure

All cancellation paths funnel into a single method:

PaymentService.cancelStripeSubscription()

This method handles:

• Immediate cancellation for unpaid or delinquent subscriptions
• Cancel-at-period-end behavior for active subscriptions
• Stripe API interactions
• Database and lifecycle updates

Centralizing this logic ensures new churn experiments do not compromise billing correctness.

Stripe and lifecycle consistency

Stripe webhooks update subscription state and trigger cancellation emails only when cancellation is newly set.

When churn occurs:

• Subscription status updates in the database
• User lifecycle flags and analytics identity are updated
• Messaging tags remain consistent across systems

Why this matters

This project reflects how I operate as a senior product engineer:

• I execute product designs faithfully while hardening system boundaries
• I treat billing and churn as infrastructure, not UI
• I centralize high-risk logic to prevent long-term maintenance debt

The result is a churn system that supports retention without sacrificing correctness or user trust.