We set up an ad-matching service – saving 72% of time on changes
Finex
The Results
Before – 4.5 hours to implement any new rule
After – 15 minutes — without code edits
Result – +18% successful deals and -40% support tickets
Technology – Instead of "spaghetti code" — we implemented a chain of independent steps (pipeline)
For three years, the platform grew with the business—buyers found the ads they needed in just a couple of clicks. But the more requirements appeared, the longer we "dug around" in the code. Each new condition led to dozens of edits and a week of testing.
We decided to remove this "bottleneck" once and for all. The goal was simple and ambitious: to make the system so flexible that any new filter or rule could be enabled in minutes—without developer involvement or business delays.
System Overview
Before – One bulky program, where any new rule "pulled a thread" of edits throughout the code.
After – A chain of independent steps—like a conveyor belt, where each block is responsible only for its own operation.
- Availability filter screens out listings where the product is out of stock. The service doesn't show empty listings, improving the user experience.
- Price check – we compare against the average market price. We remove overpriced lots to increase purchase conversion.
The New Architecture
- Pipeline. A process made of "blocks" (pipes) that run in a strict sequence. Logic can be rearranged or enabled/disabled without recompilation.
- SRP (Single Responsibility Principle) — one task = one pipe. If a new brand filter is needed, we create a separate module instead of digging into old code.
- DIP (Dependency Inversion Principle) — independence from the "internals." Pipes communicate through common interfaces; if we change an implementation, the others don't notice.
- OCP (Open/Closed Principle) — "closed" for edits, "open" for extensions. We add functionality through new modules, not by editing old ones.
- Factory Method. The system "assembles" the required set of pipes based on settings from the DB: marketing adds a new criterion → the platform picks it up on the fly.
Now the business team changes matching rules through an admin interface, not through Jira tasks for developers. Changes go to production in minutes and are immediately reflected in sales statistics.
Problem: Limited Flexibility and Complex Updates
The business team constantly added filters and coefficients, and the old mechanism couldn't keep up:
- one new condition → dozens of code changes;
- releases were delayed, tests dragged on, clients complained.
We needed to create a structure that would allow implementing new filtering rules without touching the existing code.
Solution
Flexible pipeline
A chain of independent filters. Any step can be enabled/disabled with 1 click, without a new release.
Rule management from the database
A manager changes the JSON profile without a developer. A new rule is activated in minutes.
Modular testing
Each pipe is covered by tests. The service remains stable even with frequent changes.
Caching of frequent queries
Reduced the load on the database and sped up the ad-matching process.
Results
- Flexibility and speed of adaptation — new business rules are implemented instantly, without needing code changes.
- "View → Deal" Conversion — more accurate ad matching led to an increase in successful deals.
- Reduced load on support — it's now clear why an ad failed filtering, which reduced the number of support inquiries.
- Increased performance speed — caching and code structure optimization sped up the matching process.
- Transparency and control — it's now easy to track which pipe rejected an ad, simplifying analysis and debugging.
Why This Approach Was Beneficial
What's next?
We've turned ad matching into a constructor that adapts to the market in minutes. The next step is to embed an A/B testing engine directly into the pipeline, so the business can test new rules "on the fly" and instantly see which ones actually increase revenue.