Data architecture
Relational data architecture for products and content
A relational data model designed to handle categories, variants, flavor profiles, and admin-controlled content with room to grow.
Technical narrative
This is where the archive goes deeper than the homepage: architecture choices, operating constraints, and the decisions that make the product maintainable over time.
A liquor and smoke shop catalog is not simple. Products have categories, subcategories, brands, sizes, flavor profiles, and pricing tiers. The data model needed to support guided discovery, admin management, and storefront display from the same source of truth.
The core schema uses a products table with relationships to hierarchical categories, brands, and a flexible tagging system for flavor profiles. Products support variants for different sizes and pricing. A separate content layer handles featured collections, seasonal promotions, and admin-curated product groups.
I designed the schema around the queries the application actually needs: storefront browsing, wizard matching, admin search, and analytics aggregation. Indexes are placed based on those real query paths rather than theoretical optimization alone.
The model was built to accommodate growth in categories, attributes, and content types without requiring migrations that break existing data. Generated TypeScript types keep the application layer aligned with the schema over time.