Flexible Payments System
Architected a distributed payment system enabling tenants to split monthly rental payments, supporting 75% of company revenue.
Overview
At Zego, I led a small team building FlexPay, a distributed system that lets renters split their monthly rent into several smaller payments. For a lot of people, the hard part isn't the rent itself, it's the single large payment due on the first. Spreading it out makes staying current realistic, and it pushed payment completion rates up.
What Made It Hard
Property managers wanted to offer this without taking on more operational load or risk. So the system had to handle billions of dollars in annual volume, fit into the payment infrastructure already in place, hold 99%+ uptime, and carry a partnership that accounts for as much as 75% of company revenue. No pressure.
How It's Built
The system follows Domain Driven Design, with clear bounded contexts for payment scheduling, transaction processing, and reconciliation. A React frontend talks to a GraphQL gateway, which routes requests to specialized Nest.js microservices backed by MySQL and MongoDB. Payment state changes are published as events, so other services can react without being tightly coupled to each other. That decoupling made the system easier to extend and a lot more resilient when one piece was having a bad day. We documented the architecture with C4 diagrams at a few levels of detail, mostly so new teammates could find their bearings without a three-hour whiteboard session.
Where It Landed
- 99% uptime on payment processing that genuinely can't go down
- 75% of revenue supported through the key partnership integration
- Fewer late payments, because tenants can line their payments up with their paychecks
What I Took From It
The biggest thing was how much the domain model mattered. Sitting down with product and the business to understand the real constraints of property management did more for the design than any diagram, and Domain Driven Design gave us a shared vocabulary with people who don't write code. The other lesson was less glamorous but just as true: build the observability first. You can't keep something at 99% if you can't see what it's doing.