Product catalogs don't break.
They drift.
And at some point, they stop behaving like the system they were designed to be.
The situation
A production e-commerce system with over 1,500 categories and thousands of products had been evolving for years.
At first glance, everything looked normal:
- — categories
- — subcategories
- — product attributes
- — filters
A typical hierarchical catalog.
But over time, business rules accumulated.
Products appeared in multiple categories.
Attributes depended on context.
Filtering logic varied between sections.
The system still treated the catalog as a tree.
But the data had already become something else.
The symptom
Nothing was broken.
But nothing was reliable.
Filters returned empty results where products clearly existed.
Other combinations showed products outside the expected category.
Navigation became inconsistent.
Users couldn't trust what they were seeing.
Investigation
The first instinct in these cases is to fix filters.
That's almost always the wrong place to start.
Filters are just the surface.
The structure underneath is the real problem.
The investigation focused on:
- — how categories relate to each other
- — where attributes are defined and applied
- — how products are assigned across the catalog
- — how filtering logic depends on context
Once mapped, the pattern became clear.
Root cause
The catalog had evolved from a tree into a graph.
Relationships were no longer strictly hierarchical.
- — products belonged to multiple contexts
- — attributes were context-dependent
- — rules overlapped
But the platform still assumed a simple tree structure.
This mismatch leaked into every part of the system.
Filters weren't broken.
They were operating on the wrong model.
Why this kind of problem is dangerous
Structural drift doesn't trigger alarms.
The system continues to function.
But its behavior becomes harder to predict.
In this case, a filtering rule introduced for one category silently affected several others due to shared attributes and overlapping logic.
Each new rule added complexity.
Each exception made the model less coherent.
Eventually:
- — no one fully understands how the catalog behaves
- — small changes create unexpected side effects
- — fixes become local and temporary
At that point, the system is no longer controlled.
The fix
The fix was not to "improve filtering".
It was to restore a coherent structure.
- — redefined how attributes belong to categories
- — limited cross-category logic
- — clarified ownership of filtering rules
- — removed overlapping and conflicting conditions
Conclusion
Once the structure became coherent again, the symptoms disappeared.
Filters became consistent.
Navigation made sense again.
The system became predictable.
If your system starts behaving inconsistently,
it's rarely just a bug.
It's often a sign that the underlying model no longer matches reality.
And at that point, you don't fix features.
You fix the structure.