Brand Module Backend Documentation
Backend architecture and invariants for catalog brand flows.
Summary
The brand module is a standalone catalog entity for IT Mart storefront filtering and merchandising.
Data Model
brand
| Column | Type | Nullable | Notes |
|---|---|---|---|
id | serial | no | Primary key |
name | varchar(120) | no | Unique |
slug | varchar(120) | no | Unique |
image_url | varchar(500) | no | Brand logo |
is_visible | boolean | no | Storefront display toggle |
order | integer | no | Display sort order |
product_kind | brand_product_kind enum | yes | physical, digital, both, or null |
| timestamps | created_at, updated_at |
Indexes
| Index | Type | Columns |
|---|---|---|
brand_name_idx | unique | name |
brand_name_trgm_idx | gin | name |
brand_visible_idx | btree | is_visible |
brand_order_idx | btree | order |
brand_product_kind_idx | btree | product_kind |
brand_slug_history
- old slug continuity on rename
productKind enum values
PostgreSQL enum brand_product_kind: 'physical', 'digital', 'both'.
Null means unconstrained (applies to all product kinds).
Invariants
- brand name must be unique
- slug is generated from name and suffix-resolved on conflict
- old slugs remain resolvable through slug history
- public reads return visible brands only
productKindfilter in admin list is exact match (eq)productKindfilter in customer list isOR(eq(value), eq("both"))(includes "both" brands)
Brand-to-Product Linkage
Brand-to-product linkage is now implemented. The key relationships are:
- Product level:
product.brand_id— nullable FK tobrand.id, assigned during product admin CRUD. - Warranty level:
warranty_info.brand_id— nullable FK tobrand.id, associating warranty info entries with a brand. - Warranty claim level:
warranty_claimresolves brand throughwarranty_claim.warranty_info_id -> warranty_info.brand_id -> brand.id.
All FKs are nullable — brands remain standalone entities with optional downstream associations.
Caching
Customer brand list is cached via RedisCacheService.getOrSet with a cache key that includes all query parameters including productKind. Different productKind filters produce different cache entries.
Admin mutations call invalidatePattern on catalog:brands:list:* and catalog:brand:slug:* to nuke the cache.