Guide d'architecture e-commerce

Architecture edge e-commerce : catalogue rapide, paiement sûr et défense contre les bots

Classez le catalogue public, l'état client et le trafic critique pour la transaction avant de les optimiser. La réponse la plus rapide n'est pas un succès si elle divulgue un droit ou confirme la mauvaise commande.

Publié le: 15 juil. 2026
Mis à jour le: 15 juil. 2026
Temps de lecture: 15 min de lecture

Sur cette page

Un edge e-commerce n'est pas un réglage « tout mettre en cache ». Il s'agit de trois contrats de trafic distincts : les représentations publiques du catalogue, l'état privé des comptes et paniers, et le paiement critique pour la transaction. L'edge peut mettre en cache, filtrer et protéger la capacité ; l'application reste l'autorité pour l'identité, le prix, le stock, l'éligibilité, le paiement et la validation de la commande.

Overview

Résultat

Définissez, au niveau des routes, les contrats de cache, d'origine et de contrôle des abus qui rendent les pages publiques réutilisables tout en préservant l'état privé et des décisions de commande sûres pendant le trafic normal et les pics.

Concevez trois plans de trafic

Plans de trafic e-commerce

Catalogue public
Mettez en cache les représentations publiques des produits, catégories, contenus éditoriaux et ressources versionnées.
Compte et panier
Gardez privés et autorisés par l'origine l'identité, la fidélité, les adresses et l'état du panier.
Paiement
Validez prix, stock, fraude, taxes, paiement et idempotence au moment de la validation.

Le contenu public peut s'arrêter à l'edge ; l'état client et la validation de commande conservent toujours une frontière de correction détenue par l'application.

Écrivez un contrat de cache avant de choisir un TTL

La RFC 9111 rend le comportement du cache partagé dépendant des directives de réponse et des variations. Documentez les dimensions de représentation de chaque route, la clé de cache, la fraîcheur, le responsable de l'invalidation, la politique de contenu obsolète et le test négatif. no-cache autorise le stockage mais exige une validation avant réutilisation ; no-store interdit le stockage et la réutilisation.

Classe de réponse	Politique de cache partagé	Règle de correction
Ressources versionnées	Publique, de longue durée, URL versionnée	Une ressource modifiée reçoit une nouvelle URL.
Page produit publique	Publique uniquement pour une sortie équivalente par locale, marché et canal	La clé inclut chaque variation autorisée.
Compte ou panier	`private, no-store`	L'application autorise chaque demande d'objet.
Paiement et confirmation	`private, no-store`	Revérifiez prix, stock, paiement et idempotence.

Contrat de cache représentatif

route: /products/{slug}
audience: public
cache_key: path + locale + market
freshness: business-approved
origin_rule: revalidate price and inventory at order commit
negative_test: authenticated response never enters shared cache

Protégez séparément l'origine et le paiement

Gardez l'origine privée lorsque possible, restreignez-la au chemin edge, authentifiez le trafic edge-vers-origine et testez le rejet de l'accès direct à l'origine. Traitez le paiement comme une frontière de sécurité de page de paiement : les exigences PCI DSS applicables à un environnement e-commerce incluent les scripts de page de paiement autorisés, l'intégrité des scripts, l'inventaire ainsi que la détection des changements et altérations. Un CDN ou un WAF ne remplace pas l'autorisation applicative.

Le paiement ne valide qu'après les contrôles faisant autorité

L'edge peut protéger la capacité, mais l'application doit prendre la décision finale de validation, de manière idempotente.

Telecharger:PNG SVG

Défendez-vous contre les bots selon le flux métier

Le credential stuffing, le carding, le scraping, le déni de stock et le déni de service ont des signaux et des préjudices différents. Appliquez des limites par compte, session, route, contexte d'appareil ou de réseau, et objet métier, pas par IP seulement. Utilisez des contrôles progressifs : observer, ralentir, challenger, exiger une authentification renforcée, puis restreindre les abus confirmés. Préservez un chemin de récupération accessible et des échecs de connexion génériques pour éviter l'énumération des comptes.

Préparez les chemins de défaillance lors des pics

Testez les états de cache chaud et froid, le début d'une promotion, l'épuisement des stocks, le ralentissement de l'origine, la dégradation du paiement, la vague de bots, la purge et le retour arrière. Surveillez séparément le résultat du cache, les récupérations à l'origine, la latence, les actions WAF et de limitation, les résultats de connexion et la réussite du paiement. Un taux élevé de succès du cache ne peut pas prouver que l'état privé est sûr ou que le paiement est correct.

Troubleshooting

Anti-modèles d'edge e-commerce

Mettre en cache l'en-tête Cookie complet ou du HTML authentifié sans conception d'isolation revue.
Servir un état obsolète de panier, paiement, réservation de stock ou confirmation de commande.
Considérer un CAPTCHA, la réputation IP ou un score de bot comme le seul contrôle contre la prise de contrôle de compte.
Autoriser l'accès public direct à l'origine parce que la vitrine est habituellement derrière un CDN.

Guides associés

Références faisant autorité

Examinez le chemin de diffusion avant le prochain pic

Optimi peut aider à aligner les contrats de cache, la protection de l'origine, les contrôles de bots et les preuves autour des parcours e-commerce qui comptent.

Évaluer la diffusion e-commerce