E-commerce Architecture in Metal Products Industry

In B2B ecommerce, the price is rarely the same for everyone and the buying journey may not begin with a cart. For a global metal products business, prices depend on the customer, negotiated terms and order volume. Sales reps need to prepare offers on the move, while customers around the world expect fast access to product and stock information.

A global B2B platform has to balance those customer-specific workflows with an ERP that remains the source of truth. This architecture explores identity and company roles, on-demand pricing, sales-led offers, offline tablet access and regional read models on Azure. Read on to see how it can deliver fast regional access while keeping orders and pricing consistent with the ERP.

Metal products manufacturer (B2B)

Context

The client is a wholesaler and manufacturer of metal products selling to companies worldwide. The only existing system is an ERP connected to the warehouse; that is where products, price lists, customers, credit limits, stock and orders live. Prices are not public: the catalogue can be browsed after login, and the price depends on the company, its price group, volume and negotiation. Three roles operate in the system: the sales rep, who composes offers for customers on a tablet, including in the field without connectivity; the B2B company with many users and an internal split into buyers and approvers; and the ecommerce manager managing the catalogue and visibility. Customers log in via SSO, most often with their own corporate account. Global sales require the catalogue, prices and stock to be read quickly in every region, even though there is one ERP running in one place.

Everything is built on Azure. Unlike fashion, where the architecture was shaped by scale and multi-market operation, here three tensions dominate:

• per-customer prices, calculated on demand, which cannot be pre-cached like a per-market price list;
• the ERP as the single source of truth, slow and singular, versus global customers who want answers in milliseconds;
• a sales process driven by a human (sales rep's offer, approval, deferred payment) instead of a self-service cart and online payment.

B2B Platform: system context

The B2B platform as a single system on Azure. Customers and wholesaler staff log in through Microsoft Entra, and the ERP with the warehouse remains the source of truth for products, prices, stock, credit limits and orders.

Figure 13. Diagram C1 - System Context: B2B Platform

Identity, organisations and roles

Identity is handled by Microsoft Entra in three variants: Entra ID for wholesaler staff (sales reps, ecommerce manager), with Conditional Access enforcing MFA and a compliant device managed by Intune; Entra B2B collaboration for large customers, who log in with their own corporate account via federation, with MFA and employee offboarding handled on their side; Entra External ID for small companies without their own IdP, with self-service registration and verification by the ecommerce manager. The BFF verifies tokens from the three issuers and maps the tenant/oid claim to an organisation in the commerce engine, where the actual B2B model lives: the company, its users, buyer/approver roles, price group, credit limit. The sales rep has no separate customer identity; they log in with their own account, and the BFF issues an "on behalf of company X" session with a full audit of who submitted what, and for whom.

B2B identity and roles: structure

Three Microsoft Entra token issuers: Entra ID for wholesaler staff, Entra B2B collaboration for large customers logging in via federation with their own IdP, and Entra External ID for smaller companies. The BFF verifies all three and maps tid/oid to an Organization, while the B2B model (organisations, users, roles) lives in the commerce engine.

Figure 14. Diagram: B2B identity and roles, structure

Sales rep on behalf of a company

The sales rep logs in to Entra ID, and after checking the company assignment the BFF issues a session with two identities: actor = sales rep, subject = company.

Figure 15. Diagram: Sales rep on behalf of a company, act-as sequence

Pricing and offers

The price is calculated on demand by the Pricing Engine from the base price list in the ERP, the company's price group, volume tiers and negotiated discounts; the result is cached in Azure Cache for Redis per company and per product with a short TTL and invalidated by a price list change event from the ERP. An anonymous user sees neither prices nor availability. Instead of cart and checkout, the central process is the offer: the sales rep or the buyer composes an offer with line items in wholesale units (kg, running metres, pieces, pallets, with minimum quantities), the sales rep may lower the price within their discount limit, above the threshold the offer goes to a manager for approval, and the customer accepts the offer, which becomes an order. Payment is deferred: the commerce engine checks the credit limit in the ERP at acceptance, and invoicing and settlement take place in the ERP. Before accepting an export order the system calls sanctions screening and export control, because metal products may be subject to dual-use restrictions.

ERP integration and per-region read models

The ERP cannot be queried synchronously on every customer visit: it is singular, slow and a single point of failure. The architecture applies CQRS: the write path (order, offer acceptance, limit check) goes to the ERP through an anti-corruption layer and an outbox on Azure Service Bus, while the read path is served from read models replicated to the regions. Changes in the ERP (product, base price, stock, limit) are published as events on a Service Bus topic, and consumers build read-only views in Azure Cosmos DB with writes in the ERP region (West Europe) and reads in the customer regions (East US, Southeast Asia); the search index by technical parameters (grade, dimension, standard, tolerance) is maintained in Azure AI Search per region. Azure Front Door routes the user to the nearest region, where the Storefront, BFF, Redis and read models run, while the commerce engine with its PostgreSQL database and the Pricing Engine run in the ERP region, because they need consistent transactional writes; Cosmos DB stores neither offers nor orders. The customer sees stock that is seconds old, and the final validation of stock and limit happens at offer acceptance in the write region.

B2B Platform: containers on Azure

The write region (West Europe) with the full set of services, the PostgreSQL transactional database, Service Bus and the ERP adapter over Private Link, and the read regions (×N) with their own Storefront, BFF and local read models. Writes always go to the write region, and events from Service Bus build projections in Cosmos DB and AI Search replicated to the read regions.

Figure 16. Diagram C2 - Container: B2B Platform on Azure

Sales rep tablet app

The sales rep works in the warehouse, at trade fairs and at the customer's site, often without connectivity, so the app is offline-first: a local SQLite database holds the catalogue, the price list of the company the rep is assigned to, and draft offers, and synchronisation with the BFF happens once the connection is restored, with conflict resolution at the offer level. Login via MSAL with the Microsoft Authenticator broker provides SSO with the other corporate apps, and Intune enforces device encryption and a PIN, and allows pricing data to be wiped remotely if the tablet is lost. The BFF exposes a separate contract for the tablet: an offline data package (the company's full price list, the catalogue with parameters) instead of the light per-screen responses used in fashion. The app is built in React Native, sharing the UI layer with the Storefront.

Azure components

• Azure Front Door + WAF: global edge, routing to the nearest region, static asset caching
• Azure Kubernetes Service per region: Storefront, BFF; in the write region additionally the commerce engine, Pricing Engine and projection workers
• Azure Database for PostgreSQL Flexible Server: the commerce engine's transactional database, write region
• Azure Cache for Redis per region: per-company price cache, sessions, BFF responses
• Azure Cosmos DB: read models only, projected from events; multi-region read, single-region write; no transactional data
• Azure AI Search per region: search by technical parameters
• Azure Service Bus: topics and subscriptions for ERP events and the order outbox
• ERP Adapter and read model projections: workers on AKS in the write region
• Private Link / ExpressRoute: private network to the ERP
• Microsoft Entra ID, B2B collaboration, External ID: staff and customer identity
• Intune: tablet MDM
• Azure Key Vault + Managed Identity: secrets without keys in code
• Azure Blob Storage with immutable policy: material certificates, invoices, offer documents
• Azure Monitor + Application Insights: OTel telemetry

B2B Platform: deployment on Azure

The physical view of the C2 containers. In the write region (West Europe) a full AKS cluster runs with PaaS services reachable only through private endpoints in the VNet; the read regions (×N) have only the Storefront, BFF, Redis and replicas of Cosmos DB and AI Search. Front Door routes traffic to the nearest region, writes always go to West Europe, and the ERP connects via ExpressRoute or VPN with Private Link.

Figure 17. Diagram: Azure deployment for B2B

Summary

A global B2B ecommerce platform must support customer-specific pricing, sales-led offers and fast access to product and stock information across regions. The architecture keeps the ERP as the source of truth while using regional read models and offline tools to support customers and sales reps worldwide.