Loading your next page…
Strangled a ten-year-old PHP monolith and migrated 1.2M live loans onto an event-driven core, with zero downtime and a 60% drop in P95 latency.
Every engagement is framed around the business situation, the constraint that made it hard, and the decision that turned delivery into a controlled path to value.
Situation
A ten-year-old lending core had become the bottleneck on every product initiative. The monolith owned underwriting, servicing, collections, and customer comms in a single deployable, and every release was a four-hour change window.
Constraint
A previous big-bang rebuild had been abandoned at the year-two mark. The board would not approve a second one. Whatever we shipped had to deliver value every quarter and could not interrupt loan disbursement for a single day.
Decision
Avoided a second big-bang rewrite and chose a strangler migration with value released every quarter.
Build
We mapped the monolith into bounded contexts and stood up the first new service — disbursement orchestration — alongside it. Traffic moved in measured cutovers behind a routing layer, with dual-write reconciliation for the first 30 days of each migration.
Every quarter retired a slice of the monolith and replaced it with an event-driven service on the new core. Underwriting, servicing, and collections followed in order.
Outcome
Zero missed loan disbursements during the entire nine-month migration.
P95 read latency on critical paths dropped by 62%; P95 disbursement latency dropped by 48%.
What changed after launch
Product teams moved from monthly release windows to multiple safe deployments per day, with risk and finance teams reading the same reconciliation evidence.
“MayaLogic kept the migration commercially calm. Every cutover had evidence, rollback, and a business owner before engineering touched production.”
The work was not abstract modernization. It changed day-to-day behavior, ownership, and the evidence leaders used to make decisions.
Before
After
The delivery plan made the system boundary explicit, then used rehearsals, gates, and telemetry to optimize safely before launch.
Delivery architecture
FinTech control loop
Discover
We mapped the monolith into bounded contexts and stood up the first new service — disbursement orchestration — alongside it. Traffic moved in measured cutovers behind a routing layer, with dual-write reconciliation for the first 30 days of each migration.
Build
Every cutover ran a reconciliation harness for at least two weeks, comparing every read and write between old and new systems. A divergence above 0.01% paused the cutover automatically.
Launch
SLOs were defined per service and tied to error budgets the platform team owned. The on-call rotation was practiced against synthetic incidents weekly before any cutover.
We mapped the monolith into bounded contexts and stood up the first new service — disbursement orchestration — alongside it. Traffic moved in measured cutovers behind a routing layer, with dual-write reconciliation for the first 30 days of each migration.
Every quarter retired a slice of the monolith and replaced it with an event-driven service on the new core. Underwriting, servicing, and collections followed in order.
Every cutover ran a reconciliation harness for at least two weeks, comparing every read and write between old and new systems. A divergence above 0.01% paused the cutover automatically.
Finance, risk, and operations got a daily reconciliation report in plain language — not just engineering dashboards.
SLOs were defined per service and tied to error budgets the platform team owned. The on-call rotation was practiced against synthetic incidents weekly before any cutover.
After launch
Product teams moved from monthly release windows to multiple safe deployments per day, with risk and finance teams reading the same reconciliation evidence.
A similar problem?
A senior engineer will follow up within one business day with an opinionated take on the shape of the work.
