Backend Engineering · Payments
ProductionSubscription & Payments Backend
Java/Spring Boot services for payments, subscriptions, user management and business workflows, including Stripe Connect integration with retry and fault-isolation patterns.
Portfolio-safe summary. Private source code, internal product topology and customer data are intentionally omitted.
Problem
What problem existed before the work
A growing platform needed reliable payment and subscription workflows alongside user and business services. External payment dependencies, database access and high-traffic endpoints had to behave predictably as usage increased.
Constraints
What the system had to respect
The system had to integrate an external payment provider, preserve existing business workflows, improve latency without weakening correctness, and increase automated-test coverage while continuing to serve active users.
Challenge
Why the problem was difficult
High-traffic business workflows needed predictable payment behavior, better API latency and stronger failure handling.
Approach
How I approached it
Built connector services, added retries and fault isolation, optimized SQL access, introduced targeted Redis caching and expanded automated tests around critical paths.
Architecture
How the system was shaped
Spring Boot services expose application APIs while payment-specific connector logic isolates Stripe Connect. Relational persistence remains authoritative for business state, Redis is used selectively for high-value cacheable reads, and tests cover critical service and integration behavior.
Key decisions
Decisions and reasoning
Keep payment-provider behavior behind a connector boundary, optimize database access before relying on broad caching, use Redis selectively, and add automated tests around business rules most likely to create costly regressions.
Trade-offs
What was deliberately accepted or rejected
Caching can reduce latency but introduces staleness and invalidation concerns, so it was targeted rather than used as a substitute for query optimization. Retry behavior also has to be bounded so transient provider failures do not become duplicate business actions.
Implementation
How the design moved into production
The documented work includes Java/Spring Boot backend services, Stripe Connect integration with retry/error handling and fault isolation, SQL profiling, Redis caching and expanded automated tests. Private code and internal product details remain excluded.
Reliability & security
How correctness and failure were handled
Payment-connector failure handling separated provider errors from core application behavior. Automated tests strengthened critical workflows, while database profiling and targeted caching improved performance without moving authoritative state out of the relational database.
Impact
What changed
Supported 10,000+ active users, processed documented subscription-payment volume and improved API response times by 35% through SQL profiling, Redis caching and targeted backend refactoring.
Lessons learned
What the work reinforced
Performance work is most durable when measurement comes first. SQL profiling and clear integration boundaries provide better long-term leverage than adding infrastructure before the actual bottleneck is understood.
What I’d do differently
How I would improve the next iteration
I would introduce explicit dependency-level latency and error budgets earlier so performance, provider reliability and application regressions can be compared from the same operational dashboard.
Architecture
System diagrams
Code
Sanitized implementation samples
Representative patterns only. Private repositories, internal endpoints and employer-specific implementation details are intentionally omitted.
Representative provider isolation
java
public PaymentResult charge(PaymentRequest request) {
try {
return gateway.charge(request);
} catch (TransientGatewayException e) {
throw new RetryablePaymentException(e);
}
}Illustrative code showing dependency isolation. It is not production source from the original system.