Overview and business context
I built and maintain a multi-tenant production SaaS platform supporting operational, transactional and financial workflows. The work spans application development, tenant-aware access, reporting, database performance and ongoing maintenance. This case study is anonymized to protect customer and business information.
Engineering challenge
A financial list performed repeated authorization and record-resolution work before returning a page of results. Corrections also needed to preserve historical transactions and an audit trail. Improving response time had to retain tenant isolation, permission checks and exact financial results.
Root-cause investigation
I compared before-and-after API responses and profiled database execution with synthetic local data. The query repeatedly checked permissions and resolved records to their current corrected version. This redundant work grew with the history being examined; returning fewer rows alone did not address the cost.
Technical solution
- Evaluated equivalent authorization decisions once per request while preserving tenant and record-level restrictions.
- Resolved current records once for the candidate set, then filtered and paginated before performing bounded balance aggregation.
- Designed atomic reversal-and-replacement corrections: retain the original transaction, record its reversal and link the replacement. A failed correction rolls back as one unit.
- Kept reporting and operational workflows tenant-aware, and prevented stale financial results from appearing current during failed or pending refreshes.
The read optimization preserved the existing financial writers, historical records and authorization boundaries.
Measurable result
Median full-list API response · controlled local benchmark
4,521 ms → 94 ms
Approximately 98% lower response time.
Three HTTP samples per version used the same synthetic fixture: 600 historical sales, 120 customers and a 50-row response. The unrounded medians were 4,520.77 ms and 94.12 ms, a 97.9% reduction. “Full-list” refers to the complete API call for that page, not downloading every historical record.
These are controlled local measurements, not results under real production traffic or a production latency guarantee.
Testing and production validation
Validation covered financial correctness, immutable history, correction and retry behavior, response parity, cross-tenant denial and permission boundaries. Desktop and mobile browser regressions checked navigation, pagination, refresh, error recovery and action accessibility.
Production database checks verified the intended change and preserved migration history, permissions and related definitions. Authenticated production list acceptance was unavailable for this release; local test results do not establish live-user performance. Production deployment checks are kept separate from benchmark evidence.
Related engineering Notes
How I Approach Production Problems explains the investigation and validation sequence behind this work. Database Changes Need a Delivery Plan covers compatibility and release checks, while APIs Are Where Systems Start Talking examines retries and ambiguous outcomes at application boundaries.