E-commerce Engineer

E-commerce Engineering

When product catalogs quietly become graphs

Product catalogs start simple. But as businesses grow, their structure quietly becomes something the platform was never designed to handle.

Aleksandrs — Jan 2026 — 5 min read

Most e-commerce systems assume that product catalogs are simple.

Categories form a tree.
Products belong to categories.
Filters narrow results.

In theory, this structure is straightforward.

In practice, large catalogs almost never behave like trees.

They slowly turn into graphs.

And when that happens, the system complexity explodes.

The situation

I once worked on an online store with a very large catalog structure.

At first glance it looked normal:

categories
subcategories
product attributes
filters on category pages

But the deeper you went, the more unusual the structure became.

Individual category nodes had their own sets of properties.

Products could appear in multiple parts of the catalog.

Filtering rules depended on both category context and product attributes.

The system still believed it was dealing with a simple hierarchical catalog.

But the data model had already evolved into something much more complex.

The symptom

The problems were subtle.

Filters behaved inconsistently.

Some combinations produced empty results even though products clearly existed.

Other filters returned products that did not belong in the current category context.

Nothing was technically broken.

But the user experience became increasingly confusing.

Customers could not reliably navigate the catalog anymore.

Why this happens

Most e-commerce platforms are designed around a simple assumption:

catalog = tree structure

But real businesses rarely follow such neat structures.

Over time they introduce:

cross-category product placements
category-specific attributes
marketing-driven category rules
special filtering logic

The catalog stops behaving like a tree.

It becomes a graph of relationships.

But the platform still treats it as a tree.

This mismatch is where complexity starts to leak into every layer of the system.

Investigation

When dealing with catalog issues, the first mistake teams make is focusing on filters.

But filters are usually not the root cause.

The real problem lies in the structure of the catalog itself.

The investigation started by mapping:

category relationships
attribute ownership
filter logic per category
product-category assignments

Once visualized, the pattern became clear.

The catalog structure had evolved beyond the assumptions of the platform.

The fix

The goal was not to "simplify filters".

The real task was to restore predictable structure.

That meant:

redefining how attributes belong to categories
limiting cross-category logic
clarifying filter ownership rules

Once the structure became coherent again, the filters started behaving predictably.

The lesson

Catalog complexity rarely appears overnight.

It grows gradually as business rules accumulate.

The platform keeps assuming a simple structure.

But the data slowly evolves into something much more complicated.

And when the mismatch becomes too large, the catalog stops behaving in ways anyone fully understands.

At that point, fixing filters is no longer enough.

You have to fix the structure of the system itself.

Ask a question

Have a question about e-commerce architecture, catalogs, integrations, or performance?

The most interesting questions often become future articles.

Subscribe

Get occasional engineering notes about complex e-commerce systems.

No spam. Just thoughtful observations.