Multibrand commerce architecture. Three brands, one shared platform.

React · Next.js · TypeScript · REST / GraphQL

Customer storefronts and internal tools are separate surfaces of the same platform. The multibrand frontend selects the brand at build time, reusing common journeys while keeping brand-specific presentation and behaviour behind explicit boundaries.

Shared foundation

Account, catalogue and commerce capabilities can evolve centrally instead of becoming a separate implementation for each brand.

Deliberate variation

Brand traits, capability flags, component seams, CMS adapters and design tokens preserve distinct experiences without scattering brand conditions through every feature.

Server-side ownership

Checkout and customer operations need server-side access checks. Internal operational tools coordinate multiple services; hiding a button is not a substitute for backend permission enforcement.

Python services · typed APIs · payment-provider integrations

Orders, payments, financing, fraud, gifting, fulfilment and after-sales are connected domains with different responsibilities. The difficult work is coordinating their state, not simply connecting their APIs.

Order lifecycle

Order creation, capture, shipment, tracking, returns and refunds involve multiple transitions, including partial payments and split fulfilment.

Market-specific rules

Payment methods, financing eligibility, currencies and provider configuration vary by market and brand while using shared transaction contracts.

Customer and partner boundaries

CRM, retail inventory, communication and after-sales integrations extend the platform beyond the storefront and need clear sources of truth.

Azure Service Bus · RQ / Redis · SQL scheduling · SQS / Lambda

The platform uses more than one asynchronous execution model. Event consumers, local jobs, scheduled business changes and serverless tasks have different ordering, persistence and retry requirements.

Azure event transport

Queues handle dedicated processing paths; topics and subscriptions let independent integrations react to relevant events. Consumers have their own completion, retry and dead-letter responsibilities.

RQ background jobs

Redis-backed RQ workers handle retail inventory-cache refresh and access-log work outside request handling. Job storage must be assessed separately from rebuildable cache storage.

Scheduled and serverless work

A database-backed scheduler persists future price changes. Asset tasks use SQS and Lambda. These are distinct mechanisms, not different names for the same queue.

PostgreSQL · DynamoDB · Algolia · Redis-compatible caches

The commerce core, configuration and customer domains own different data. Search indexes and a relational replica provide specialised read models derived from upstream changes; they are not automatically the authority for financial transactions.

Derived read models

Event consumers update search and relational projections for discovery, operational queries and exports. Supported replay paths can fetch current upstream data rather than reapply an obsolete payload.

Brand and market context

Configuration, customer data and indexes need explicit brand/market scope. Shared infrastructure must not imply unintentional sharing of customer or commercial state.

Freshness and recovery

Caches and projections require invalidation, freshness monitoring and rebuild strategies. A submitted indexing task is not the same as a result already being searchable.

AWS EKS · Docker · Terraform · Cloudflare · observability

Container workloads, infrastructure-as-code and edge policies form the operating environment. APIs, event consumers and maintenance jobs have different resource, scaling and recovery characteristics.

Workload separation

Kubernetes manifests distinguish APIs, workers and scheduled jobs, with independent replica counts, resource budgets, health checks and secret integration.

Edge policy

Domain routing, locale redirects, cache keys, security rules and maintenance behaviour are part of the platform contract, not decorative infrastructure.

Edge coordination

Cache-warming work uses Worker service bindings, KV and Durable Objects to coordinate dispatch, regional completion, duplicate callbacks and recovery deadlines.

Versioned contracts · CI/CD · cross-repository coordination · QA

A shared platform evolves across independent repositories, package versions and release boundaries. Delivery governance connects architecture decisions to changes that can be reviewed, verified and traced.

Cross-repository evolution

Shared authentication, market and payment contracts require compatible rollout. Repository coordination tracks source revisions rather than treating a folder of clones as a release.

Layered verification

Service tests, frontend tests, journey checks and operational diagnostics answer different questions. A broad test inventory is not a guarantee that every cross-brand business flow is covered.

Accountable ownership

Architecture direction, release policy, vendor choices, team responsibilities and operational readiness must support the same business objective.