Schéma d'architecture e-commerce : catalogue, panier, checkout et commandes

À 9 h 00, les soldes commencent. Le CDN maintient les pages produit en ligne, mais le checkout échoue : deux acheteurs prennent le dernier exemplaire de la même veste, une nouvelle tentative après un timeout laisse deux blocages de paiement sur une seule carte, et l'entrepôt apprend l'existence d'une commande une heure trop tard parce qu'un événement s'est perdu.

Aucun de ces problèmes n'est un problème de capacité. Ce sont des problèmes de frontières : qui possède quelles données, et quelles étapes doivent se terminer pendant que l'acheteur attend.

Cet article présente une architecture e-commerce réaliste pour une boutique de taille moyenne : composants et propriété des données, le chemin de checkout pas à pas, le pipeline de commande qui suit, les pics de trafic et un schéma de la plateforme.

Partir de ce que font les acheteurs

Cinq parcours couvrent l'essentiel de l'activité d'une boutique, avec des exigences très différentes :

La navigation et la recherche portent la plupart des requêtes et tolèrent des données périmées ; le checkout en porte peu et n'en tolère aucune. L'essentiel de l'architecture découle de cette séparation.

Les composants et les données que chacun possède

À la périphérie, un CDN met en cache les pages et les images, et une passerelle API (ou un backend for frontend par type de client) authentifie, limite le débit et route le reste. Chaque service derrière elle possède ses données :

Les autres services utilisent l'API ou les événements du propriétaire, jamais ses tables. Le stock et les commandes exigent des transactions ; les paniers et l'index de recherche peuvent prendre du retard, voire perdre une écriture, sans véritable dommage.

Le chemin de checkout, pas à pas

Le checkout est le seul flux où l'acheteur attend plusieurs services à la fois :

1. Recalculer le prix du panier. Checkout lit le panier, récupère les prix actuels auprès du catalogue et calcule la taxe, la livraison et les remises côté serveur. Ne faites jamais confiance au total d'un navigateur.

2. Réserver le stock avec une expiration, ici 15 minutes :

   -- One transaction: take the stock, then record the hold
   UPDATE stock SET reserved = reserved + 2
    WHERE sku = 'JKT-042-M' AND on_hand - reserved >= 2;  -- 0 rows: out of stock, stop
   INSERT INTO reservations (checkout_id, sku, qty, expires_at)
   VALUES ('chk_41a', 'JKT-042-M', 2, now() + interval '15 minutes');
   

   Quand deux acheteurs se disputent la dernière veste, le niveau d'isolation par défaut de PostgreSQL, Read Committed, fait attendre la seconde mise à jour puis revérifie sa clause WHERE sur la nouvelle ligne, de sorte que l'un obtient zéro ligne. Un sweeper rend les réservations expirées au stock. Avec une page de paiement hébergée, alignez les horloges : les sessions Stripe Checkout durent 24 heures, sauf si vous fixez une expiration plus courte (30 minutes minimum) ou les faites expirer vous-même ; checkout.session.expired vous indique quand libérer les articles.

3. Créer le paiement avec une clé d'idempotence. Checkout demande au PSP un paiement du total calculé côté serveur, avec capture manuelle et une clé d'idempotence enregistrée avant l'appel. Après un timeout, réessayez avec la même clé : Stripe renvoie la réponse enregistrée au lieu de créer un second paiement. Ses clés font jusqu'à 255 caractères et peuvent être purgées après 24 heures.

4. Autoriser. Prolongez d'abord la réservation de stock, pour qu'elle n'expire pas en plein paiement. L'acheteur saisit ses données de carte dans les champs du PSP, donc les numéros de carte n'atteignent jamais vos serveurs, et l'émetteur peut demander 3-D Secure. En cas de succès, les fonds sont bloqués : un paiement Stripe avec capture manuelle passe à requires_capture et émet payment_intent.amount_capturable_updated. Faites confiance à ce webhook, pas à la redirection du navigateur ; voir le schéma d'intégration d'une passerelle de paiement.

5. Passer la commande. Orders crée la commande à l'état placed et écrit OrderPlaced dans une table outbox dans la même transaction. Checkout demande ensuite à Inventory de transformer la réservation en allocation.

6. Capturer à l'expédition. Quand Fulfillment expédie, Orders capture. Au moment de la rédaction (novembre 2026), Stripe documente que les autorisations de carte en ligne durent généralement 7 jours, ou 5 jours (exactement 4 jours et 18 heures) pour les transactions Visa initiées par le commerçant ; ensuite les fonds sont libérés et le paiement est annulé. La plupart des paiements par carte n'autorisent qu'une capture, et une capture partielle libère le reste.

Si une étape échoue avant que la commande n'existe, annulez les précédentes dans l'ordre inverse : annulez l'autorisation, libérez la réservation. C'est une saga dont le checkout est l'orchestrateur.

Où l'argent, le stock et l'état de la commande changent

Les cas difficiles se situent entre les lignes. Si une autorisation arrive après l'expiration de la réservation, réservez à nouveau s'il reste du stock ; sinon, annulez l'autorisation et prévenez l'acheteur. Si une précommande dépasse la fenêtre de 7 jours, capturez le montant total à la première expédition, utilisez une autorisation étendue là où votre PSP en propose une (jusqu'à 30 jours sur certains réseaux de cartes, selon Stripe), ou débitez d'avance et remboursez ce que vous ne pouvez pas expédier. Certains moyens de paiement, comme ACH et iDEAL, ne permettent pas du tout de capturer séparément.

Après la passation de la commande

Tout ce qui suit placed s'exécute de façon asynchrone. Un relais publie OrderPlaced depuis l'outbox vers le topic order-events, de sorte qu'aucun événement ne se perd entre le commit et le broker (voir le pattern transactional outbox). Fulfillment prépare, emballe et expédie, puis publie OrderShipped, ce qui déclenche la capture. Notifications envoie les e-mails ; Analytics charge chaque événement dans l'entrepôt de données.

La livraison est au moins une fois, donc les consommateurs dédupliquent par identifiant d'événement. Clé le topic par identifiant de commande pour garder les événements de chaque commande dans l'ordre.

Le schéma d'architecture microservices débite plutôt la carte après OrderPlaced. Cela convient aux paiements sans interaction de l'acheteur ; 3-D Secure exige sa présence, donc cette conception autorise dans le checkout.

Survivre aux pics de trafic

Supposez une heure de soldes avec 7 200 commandes, un taux de conversion de 2 % et 10 pages vues par session : 360 000 sessions et 3,6 millions de pages vues, soit environ 1 000 pages vues par seconde pour 2 commandes par seconde. Chaque moitié a besoin de sa propre protection :

• Mettre le catalogue en cache en périphérie. Avec Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60, le CDN sert une page produit pendant cinq minutes, puis jusqu'à une minute de plus pendant qu'il la recharge en arrière-plan, comme le définit la RFC 5861. Avec 90 % de taux de succès, l'origine voit 100 pages vues par seconde au lieu de 1 000. Purgez lors des changements de prix ; le checkout revérifie de toute façon.
• Placer une file d'attente devant le checkout. Une salle d'attente virtuelle admet les acheteurs à un rythme que Inventory et le PSP peuvent soutenir, comme dans la conception d'un système de réservation de billets.
• Protéger les SKU populaires. Les réservations d'un SKU mettent à jour une seule ligne, une à la fois. À 2 ms de temps de verrouillage par transaction, cette ligne plafonne vers 500 réservations par seconde. Gardez la transaction courte et sans appel au PSP, répartissez le stock d'un article d'appel sur plusieurs lignes et plafonnez la quantité par commande.
• Connaître les limites de débit de votre PSP avant les soldes.

Commencez plus petit que ça

Beaucoup de boutiques ne devraient pas tout construire. Une plateforme hébergée comme Shopify ou BigCommerce exécute le catalogue, le panier et le checkout pour vous ; votre schéma montre alors les applications et les webhooks autour.

Un développement sur mesure démarre souvent mieux en monolithe modulaire : les mêmes frontières sous forme de modules dans un seul déployable. En 2019, les ingénieurs de Shopify ont décrit la réorganisation de l'une des plus grandes bases de code Ruby on Rails autour des commandes, de l'expédition, du stock et de la facturation, au lieu de la découper en microservices. Extrayez un service quand un module a besoin de sa propre mise à l'échelle ou de ses propres versions ; le schéma s'applique toujours.

Le schéma de la plateforme e-commerce

Comment le lire :

• Les requêtes entrent en haut à gauche : acheteur, CDN, puis la passerelle, qui route chaque parcours vers un service.
• Le bleu est le chemin de navigation. L'arête en pointillé est l'index de recherche qui rattrape les changements de produits.
• L'ambre est le chemin de checkout, où l'acheteur attend : lire le panier, réserver le stock, autoriser et passer la commande.
• Le prestataire de paiement reçoit deux appels : l'autorisation pendant le checkout et la capture sur OrderShipped (turquoise en pointillé).
• Les arêtes violettes en pointillé sont des événements, de l'outbox via order-events vers Fulfillment, Notifications et Analytics.
• Chaque service nomme son stockage, et le bloc Markdown liste les chiffres.

Dessiner clairement des schémas d'architecture e-commerce

• Étiquetez les arêtes de la passerelle avec des routes comme GET /products, pour que les lecteurs associent les pages aux services.
• Nommez le stockage sur chaque service. Une base de données partagée doit être impossible à manquer.
• Trait plein pour l'attente, pointillé pour plus tard. Les appels que l'acheteur attend doivent se distinguer des événements.
• Écrivez les durées sur les arêtes. La durée de réservation et le déclencheur de la capture sont ce qui demande le plus de relecture.
• Dessinez l'autorisation et la capture comme deux arêtes. Une seule flèche vers le PSP masque le timing clé.
• Laissez de côté les pods, les régions, les prestataires de taxe et de lutte contre la fraude, et le back-office.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez une Personne depuis le pack C4 Model, puis un CDN et une Passerelle API depuis le pack Cloud en dessous.
3. Ajoutez cinq nœuds Conteneur du pack C4 Model en colonne : Catalog, Search, Cart, Checkout et Orders, chacun avec son stockage dans la description.
4. Ajoutez un Conteneur pour Inventory, un Système externe pour le prestataire de paiement et un Sujet du pack Données pour order-events. À leur droite, ajoutez des nœuds Conteneur pour Fulfillment et Notifications et un Entrepôt de données du pack Données.
5. Reliez la passerelle aux cinq services avec des étiquettes de route. Tracez les appels de checkout en trait plein, et les changements de produits, la capture et les événements en pointillé.
6. Ajoutez un bloc Markdown du pack Base avec les chiffres, et des notes Texte pour la légende et les règles clés.

Si vos services tournent depuis un fichier Compose, l'outil Docker Compose vers diagramme ébauche les boîtes ; le modèle d'architecture microservices est un autre point de départ. L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quels sont les principaux composants d'une architecture e-commerce ? Un CDN, une passerelle API, des services pour le catalogue, la recherche, le panier, le checkout, le stock et les commandes, un prestataire de paiement, ainsi que Fulfillment, Notifications et Analytics. Les plateformes hébergées regroupent la plupart d'entre eux.

Une boutique en ligne devrait-elle utiliser des microservices ? Pas par défaut. Un monolithe modulaire avec les mêmes frontières est plus simple à exploiter, et Shopify en a choisi un pour son cœur. Extrayez un service quand un module a besoin d'une mise à l'échelle ou de versions indépendantes.

Comment éviter la survente de stock ? Réservez le stock avec une mise à jour atomique et conditionnelle par SKU, donnez une expiration à chaque réservation et n'allouez qu'au moment où la commande est passée. Ne décidez jamais de la disponibilité d'après une page en cache.

Quand une boutique en ligne doit-elle capturer le paiement ? Pour les biens physiques, généralement à l'expédition, afin de ne facturer que ce qui part. Les autorisations de carte en ligne durent généralement 7 jours. Sur Stripe, Klarna autorise 28 jours et PayPal 10, que Stripe tente de prolonger à 20.

Comment les sites e-commerce gèrent-ils les pics de trafic ? Ils servent le catalogue depuis le CDN, mettent les acheteurs en file d'attente devant le checkout et protègent les SKU populaires et le prestataire de paiement. Planifiez la capacité du checkout séparément des pages vues.

Commencez gratuitement — un siège, sans carte bancaire.