Introduction

Blindstrader is a B2B supply-chain platform for the window covering industry. It connects Brands (fabric and component manufacturers), Suppliers (made-to-measure fabricators), and Retailers (customer-facing storefronts) in a structured three-tier flow.

The Three Account Types

Accounts in Blindstrader are mutually exclusive — each organisation is one of:

Type	Examples	Core role
Brand	Louvolite, Coulisse, Top Window Covering	Fabric/component manufacturers. Own the verified master catalog.
Supplier	Cassidy, Stewarton, Blindlux	Made-to-measure fabricators. Import Brand catalogs, add pricing, sell to retailers.
Retailer	Newblinds	Customer-facing stores. Adopt supplier products, process end-customer orders.

The Three-Tier Supply Chain

Brand  ──────►  Supplier  ──────►  Retailer  ──────►  End Customer
(master catalog)  (pricing + fab)   (storefront)      (purchase)

1. Brand creates a verified master catalog (fabrics, blind types, components).
2. Supplier connects to a Brand, imports the catalog with their own markup/pricing, and fabricates finished blind products.
3. Retailer connects to a Supplier, adopts the product catalog, sets retail pricing, and serves end customers.
4. Customer places an order on the retailer storefront — the payment is automatically split across Brand / Supplier / Retailer / Platform via Stripe Connect.

Key Concepts

Verification Chain

The Brand's "blue tick" verification propagates downstream automatically:

• brand_fabrics.brand_verified = true — set by the Brand in their tenant database.
• supplier_products.is_brand_verified — computed from the imported Brand catalog.
• retailer_products.brand_verification_status — one of fully, partial, or none depending on what components are verified.

Database-per-Tenant Isolation

Every Brand, Supplier, and Retailer organisation gets its own dedicated MySQL database:

Tenant type	Database naming
Brand	blindstrader_brand_{slug}
Supplier	blindstrader_supplier_{slug}
Retailer	blindstrader_retailer_{slug}

This means one tenant's data is never co-mingled with another's, and a spike in one tenant's traffic does not affect others.

Event-Driven Communication

Services communicate asynchronously via Apache Kafka. When a Brand updates their catalog, a BrandCatalogUpdated event is published; downstream Suppliers consume it and can opt in to sync the changes. No service calls another service's HTTP endpoints for business logic — only the event bus.

Microservices at a Glance

Service	Responsibility	Default port
Identity	SSO auth, RBAC, partner discovery	8001
Brand	Brand tenant federation, catalog management	8002
Supplier	Supplier operations, inventory, fulfillment	8003
Supply Chain	Order orchestration, fulfillment rules	8004
Payment	Stripe Connect split payments, ledgers	8005
Retailer	Customer storefronts, catalog overrides	8006
Platform Ops	Billing, analytics, system administration	8007
Notification	Email, SMS, Slack alerts	8008

Next Steps

• Brand users → Brand Account Guide
• Supplier users → Supplier Account Guide
• Retailer users → Retailer Account Guide
• Developers / integrators → Architecture Overview and API Reference