Optimizing Automated Deal Matching
RiseX
The platform’s automated deal-matching system had been working reliably for several years. Nevertheless, as the platform scaled, a predictable issue emerged: some transactions were being created even though the required payment details (requisites) were no longer available. This led to:
- User funds being frozen in unfulfillable transactions
- The database filling up with unnecessary transaction records
- Increased system load with no real benefit
In practice, this looked like the following: out of every 1,000 created transactions, around 200 had to be canceled because the selected listing had no available requisites left, making it impossible to assign one to the transaction. The issue only surfaced after the transaction was created, when the system tried to attach a requisite and failed. This added avoidable load to the database and job queues, and negatively impacted the user experience.
After revising the algorithm, the system began checking the availability of requisites during the listing selection phase, before a transaction was created. This allowed the platform to skip listings with exhausted requisites upfront, significantly reducing unnecessary operational load.
Objective
We needed to design a reliable mechanism that would:
- Automatically exclude requisites that have reached their usage limits
- Ensure that each created transaction can actually be completed
- Allow users to define a custom priority for how their requisites are used
A key requirement was that the upgrade had to be deployed without any service downtime.
What We Did
Requisite Limit Tracking
Each requisite is now paired with a tracking system that records:
- The number of times it’s been used
- The total volume of associated transfers
- Its live status relative to set limits
Once a limit is reached, the requisite is automatically excluded from the available pool.
Requisite Selection Logic
When a requisite becomes unavailable, the system follows one of two selection strategies:
- Random selection — chooses from the available options
- User-defined priority — follows the order configured in the user's dashboard
This gives flexibility to align system behavior with user preferences or business rules.
Limit Updates via Events
Limit changes are processed using Laravel’s event system:
- If a transaction is completed — requisite stats are updated
- If a transaction is canceled — stats remain unchanged
This event-driven architecture replaces heavy background checks and makes the system far more scalable.
Early-Stage Filtering
Listings with only exhausted requisites are now filtered out before a transaction is created. This prevents the system from wasting resources on unfulfillable transactions and keeps the database lean.
Results
- The system stopped creating “dead-end” transactions
- Redundant operations and DB queries were significantly reduced
- Transaction creation became faster and more predictable
- Platform stability and reliability improved
- Users gained clear control over how their requisites are prioritized
Tech Stack
- Laravel — core framework, event system, job queues
- Redis — used for caching requisite limits, tracking counters, and powering queues (Redis driver)
- Laravel Queue — async job processing for updating stats and handling events
- MySQL — primary data store for user preferences and final values
Why It Matters
Challenges like this aren’t solved with off-the-shelf tools. They require a deep understanding of business logic, stable architectural planning, and precision when working with transactional systems.
We don’t just write code — we integrate into the most sensitive parts of your infrastructure and make them reliable, scalable, and production-ready.