How a shop of twelve thousand books is put together.

A book sits in one place on the shelves — three levels deep, thirteen sections down to a hundred and twenty-five shelves. That is the category tree, and it answers "where do I walk to".

Everything else a book is — author, publisher, format, condition, language, decade, reading age, length — is an attribute. Attributes answer "narrow this down". The distinction matters because attributes combine and categories do not: a customer wants a used hardback under ten pounds, and that is three attributes crossing one shelf.

The named views in the navigation — New in, Staff picks, Second-hand, Offers — are not extra categories either. They are saved filters with a readable address, so the shop can add "Signed editions" on a Tuesday without touching the tree.

WooCommerce filters products by joining the taxonomy tables once per attribute. With one filter that is fine. With four filters, a price range and a sort order it becomes a query the database has to think about — and at twelve thousand titles it thinks for over three seconds.

So the filters run on a purpose-built index instead: one narrow table holding product → facet → value, read with an existence test per condition rather than a join per condition. The catalogue tables stay exactly as WooCommerce expects them, which means every plugin, import and report still works. Rebuilding the whole index takes eight seconds; a single product updates itself the moment it is saved.

The counts beside each filter option — "Hardback 6,926" — are the expensive part, not the results. Computing them naively means running the whole intersection once per facet. Here the matching set is materialised once into memory and each facet counted against it, which is the difference between 15.6 seconds and 53 milliseconds.

WordPress search matches with a wildcard scan across post content. It cannot rank, it cannot see custom fields, and it does not find an ISBN at all — the ISBN lives in product metadata, so a customer typing the number off the back of a book gets nothing.

Search here runs on a full-text index over title, author and description, with an exact-code path in front of it for ISBNs and SKUs. Two details decide whether it feels right: short words and stop-words must not be required terms, or "ursula le guin" returns nothing at all; and the fallback has to match word by word rather than as one string.

A title is not a thing you can buy. A paperback in very good condition is. So a book with more than one edition on the shelf is a variable product: format crossed with condition gives the buyable rows, each with its own price, stock and barcode. Twelve thousand titles come to 20,871 buyable SKUs.

This is also why the ISBN is the SKU rather than an invented code. ISBN-13 is already the barcode on the back of the book, so the number on the shelf label, the number in the shop's system and the number a scanner reads are the same number.

The hard part of "the shop maintains this itself" is not whether someone can edit a price. It is making sure the person editing a price cannot delete a category — because removing a term takes every book's place on the shelves with it, and nothing brings that back.

So the back office has three roles instead of one. Booksellers work the counter; buyers build the catalogue; the manager holds everything that cannot be undone. Nobody but the owner sees plugins, themes or users.

The structure above does not change as the catalogue grows — that is the point of settling it first. What changes is the machinery underneath, and it changes at predictable sizes rather than all at once.

Two decisions taken now are what make this possible later, and both are cheap today and expensive to retrofit: never put a filterable property in the category tree, and keep the catalogue tables standard so the fast paths can be added or removed without a migration.