ActivePOS XA

• ~60% higher throughput
• 20+ businesses served
• BIR-accredited

Problem

Data processing slowed down under peak load at busy stores, and the usual fixes (more hardware, more retries) made no lasting difference.

Approach

• Profiled the slow paths and traced the stall to an ORM concurrency and FireDAC connection-pool defect
• Fixed the dangling object manager at the root instead of working around it in queries
• Verified the change against production-like load before rolling it out

The connection-pool defect

The slowdown came from a dangling object manager in the ORM layer, which interacted badly with the FireDAC connection pool under concurrent load.

I fixed it at the root instead of adding retries or caching around it. Data-processing throughput rose by about 60%.

1. Profile the slow paths
2. ↓→Trace to a dangling object manager
3. ↓→Fix pooling at the source
4. ↓→Verify under production-like load

Compliance reporting

I built the BIR-compliant reports: end-of-shift, end-of-day, sales and tax. Each exports to PDF.

Real-time adapter

I wrote a Socket.IO adapter using the observer pattern, so the POS can push live updates to connected clients.

Refactor toward Clean Architecture

I refactored sales orders, discounts, payments and reports toward Clean Architecture and DDD, with DUnitX tests around the code I moved. I was also the first engineer on the project to take in client and operations requirements.

Outcome

Throughput rose by about 60% with no schema changes, and peak-hour slowdowns stopped.