Introduction
When building automatic size chart display, how you store the data matters as much as the selection logic itself. There are dozens of chart types, the product-side inputs arrive with spelling variations, and the assignments — which chart goes with which product — keep changing as the store operates.
This article explains the data design behind the size chart system: how chart data is saved, how normalization absorbs inconsistent inputs, and the two-layer setup that lets administrators change assignments from the admin screen. By the end, you should see the thinking that turns "something that works" into "something you can keep operating."
How Chart Data Is Stored
One file per chart
Size chart data is stored as one file per chart, in JSON (a text file format for settings and table data). Rather than bundling every chart into one giant file, each chart deliberately stands alone.
The folder holding all chart data
The list of available charts
One file per chart
In one sentence: a table-of-contents file sits alongside individual content files, kept separate on purpose. With one chart per file, fixing a single chart never risks touching the others.
IDs you can read at a glance
Every chart gets an ID that reveals its target on sight, following the pattern "category prefix + gender + item type."
"outer-men-jacket" can only mean the men's outerwear jacket chart. When you operate dozens of charts, that read-it-and-know quality translates directly into fewer management mistakes.
What each file contains
Each individual file holds the chart's ID, name, and target (category, item type, gender), plus the size table shown on screen and a measurement guide (instructions like "chest: measure horizontally at the fullest point" or "height: measure without shoes"). Everything needed for display lives in one file, so adding a chart means adding one file and listing it in the index — nothing more.
Normalization: Absorbing Spelling Variations
Assume inputs will vary
Category and gender values are entered by people, so they will vary — "women," "woman," and "ladies" end up coexisting. Solving that with an operational rule ("please enter values consistently") fails the day someone doesn't, and the chart silently stops appearing.
Instead, a normalization step converts inputs into a fixed form before any matching happens. Inconsistent input is accepted as-is and absorbed by the system.
Category matching rules
Category is judged by keywords contained in the input value.
In one sentence: if a distinctive word appears anywhere in the input, the product is classified into that category. Because no exact match is required, modest spelling variations classify without trouble.
Gender matching rules
Gender follows the same idea, collapsing common spellings into four groups.
Anything unrecognized becomes unisex. Rather than erroring out on an unclassifiable value, the system routes it to the safest catch-all — and chart display never stops on unexpected input.
Two-Layer Assignment Management
A standard table plus an override table
The mapping — which combination gets which chart — is managed in two places: a standard table built into the code, and an override table in Vercel KV (a small cloud data store writable from the admin screen).
Built into the code. The baseline assignments
Overrides editable from the admin screen
Checks overrides first, falls back to the standard table
In one sentence: only the assignments you want changed are overridden in KV, and everything else runs on the standard table.
Why two layers
With only the standard table, every assignment change would require redeploying the site. With only KV, a KV outage would take down every size chart at once. Two layers give you both: day-to-day changes apply instantly from the admin screen, and if KV ever becomes unreadable, the standard table keeps charts on screen. Easy to change, hard to break.
Retrieval Flow and Caching
How the product page gets its chart
The product page fetches its size chart through an API (the behind-the-scenes window a page uses to request data).
In one sentence: the page hands over product information, the matching and loading happen behind the scenes, and a display-ready chart comes back.
Cache what rarely changes
Size charts change infrequently, so the system leans on caching (keeping prepared results ready to serve) at every layer.
With caching effective at all three layers, size chart display stays fast even under heavy traffic. Cache what doesn't change; check fresh only what does — the basic shape of cache design.
Summary
The size chart data structure comes down to four decisions: one file per chart, normalization that absorbs spelling variations, a standard-plus-KV two-layer mapping, and three layers of caching. Inconsistent input is accepted by design, changes apply instantly from the admin screen, and even during an outage the standard table keeps things running. It's data design with ongoing operation built in from the start.
How this data feeds the matching order, and how users get size recommendations from it, are covered in the companion articles.