Référence d’application. Il s’agit d’une architecture illustrative et d’une checklist de périmètre, et non d’un projet client vérifié ni d’un déploiement mesuré. Les technologies, le périmètre d’intégration et les éléments livrés sont convenus en fonction du cahier des charges réel.
Scénario et contraintes
Une marque de vente au détail vendant via un mini-programme WeChat tout en exploitant également des magasins physiques. L’exigence impérative est que le stock reste correct entre les canaux pendant les promotions : un stock de canal mis à jour indépendamment peut créer un risque de survente, sauf si les règles de réservation, de synchronisation et de rapprochement sont définies. Les points de fidélité et les coupons doivent également être comptabilisés de manière cohérente, car l’application deux fois d’une remise constitue une perte financière directe.
Architecture
Couches et responsabilités
| Couche | Technologie | Responsabilités |
|---|---|---|
| Client | UniApp (WeChat + Douyin depuis une même base de code) | Navigation dans le catalogue, panier, commande/validation du panier, centre des membres. Aucune règle métier n’est considérée comme fiable ici ; le client ne fait qu’afficher l’état confirmé par le serveur. |
| API | Go + Gin, sans état derrière un équilibreur de charge | Validation des requêtes, authentification, règles métier, limites transactionnelles. Évolutivité horizontale, car aucun état de session ne réside dans le processus. |
| Cache | Redis | Données de catalogue fréquemment consultées, compteurs de stock pour les ventes flash, verrous distribués, clés d’idempotence pour les callbacks de paiement. |
| Stockage | MySQL avec réplica de lecture | Données faisant autorité. Les écritures vont vers la base primaire ; les lectures du catalogue et des rapports peuvent être orientées vers un réplica lorsque le volume de lectures le justifie. |
| Administration | Vue 3 + Element Plus | Gestion du catalogue, des commandes, des stocks, des promotions et des magasins, avec des autorisations imposées par le backend. |
| Asynchrone | Workers de file d’attente | Rapprochement des paiements, envoi de messages, agrégation des rapports, libération du stock à l’expiration d’une commande — tout ce qui ne doit pas bloquer la requête de commande/validation de commande. |
Modèle de données
Les tables ci-dessous portent les règles dont tout le reste dépend. Une mauvaise conception de ces éléments transforme une démonstration fonctionnelle en un système impossible à étendre.
Entités principales
| Entité | Champs clés, relations et règles |
|---|---|
| product / sku | Un produit correspond à plusieurs SKU selon la combinaison d’attributs. Le prix et le stock dépendent du SKU, jamais du produit ; sinon l’extension d’une tarification multi-variantes devient impossible. |
| inventory | Lignes indexées par (sku_id, location_id) contenant on_hand et reserved. Le stock disponible est dérivé comme on_hand moins reserved ; les transactions et le rapprochement doivent néanmoins être testés pour détecter les écarts. |
| inventory_txn | Registre en ajout uniquement de chaque mouvement de stock, avec code motif et commande source. Le stock courant doit toujours pouvoir être reconstitué en rejouant ce registre — c’est ce qui rend les écarts auditables plutôt que contestables. |
| order / order_item | La commande porte la machine à états et les totaux ; les éléments enregistrent le titre, la spécification et le prix unitaire du SKU au moment de l’achat afin que les modifications ultérieures du catalogue ne puissent pas réécrire l’historique des commandes. |
| payment_txn | Identifiant de transaction de la passerelle, montant, statut et charge utile brute du callback. Unicité sur l’identifiant de la passerelle afin qu’un callback WeChat Pay répété ne puisse pas être appliqué deux fois. |
| member / point_txn / coupon | Le solde et les points du membre sont dérivés d’un journal de transactions en ajout uniquement. Les lignes de coupon portent la portée, le seuil, la priorité de cumul et un horodatage used_at utilisé pour imposer l’usage unique. |
Interfaces clés
Endpoints portant les règles métier
| Endpoint | Objectif et remarques sur la concurrence |
|---|---|
| POST /api/v1/orders | Crée la commande et réserve le stock dans une seule transaction de base de données. Sous une charge de vente flash, la réservation passe d’abord par une décrémentation atomique Redis, MySQL faisant foi pour le règlement ; le client transmet une clé d’idempotence afin qu’un double appui ne puisse pas créer deux commandes. |
| POST /api/v1/payments/callback | Callback de la passerelle. Idempotent sur l’identifiant de transaction de la passerelle, il vérifie la signature et fait progresser l’état de la commande. Il ne renvoie un succès qu’après validation et commit en base de données de la modification d’état ; sinon la passerelle continue ses tentatives. |
| POST /api/v1/orders/{id}/cancel | Libère le stock réservé et rétablit la consommation du coupon et des points dans la même transaction que celle qui clôture la commande. |
| GET /api/v1/skus/{id}/availability | Lit le stock disponible via le cache avec un TTL court. La disponibilité affichée peut intentionnellement accuser un retard ; seule la transaction de commande fait autorité. |
| POST /api/v1/admin/inventory/adjust | Écrit un inventory_txn avec un code motif et un identifiant d’opérateur plutôt que de mettre directement à jour un nombre de stock. Chaque correction manuelle reste traçable. |
Choix techniques
- UniApp plutôt que des mini-programmes natifs séparés. WeChat et Douyin partagent la majeure partie du parcours commercial ; une seule base de code évite donc la maintenance en double. Les paiements et connexions propres à chaque plateforme sont isolés derrière une couche d’adaptation plutôt que dispersés dans les pages.
- Stock réservé au placement de la commande, et non au paiement. Réserver au moment du paiement signifie qu’un client peut payer un article déjà vendu. Le compromis est que les commandes impayées immobilisent le stock ; les réservations expirent donc selon un délai et un worker les libère.
- Disponibilité dérivée, jamais stockée. Une valeur available_qty mise en cache introduit un chemin de synchronisation supplémentaire. Une disponibilité dérivée peut réduire cette duplication ; comparez les performances de lecture et le comportement du rapprochement pour la charge réelle.
- Registres en ajout uniquement pour le stock, les points et le solde. Tout montant susceptible d’être contesté par les clients doit pouvoir être reconstitué à partir d’un journal ; sinon le support ne peut pas expliquer un écart.
- Go pour la couche API. La charge consiste en de nombreuses requêtes courtes et concurrentes autour d’une base de données, ce qui convient au modèle de concurrence de Go, tandis qu’un binaire statique unique simplifie le déploiement et le retour arrière.
Objectifs de conception hypothétiques
Les chiffres ci-dessous sont des exemples hypothétiques de planification de capacité, et non des résultats clients mesurés, une recommandation de dimensionnement validée ou un SLA. Définissez des objectifs d’acceptation propres au projet après avoir défini la charge, les appareils, les données, le matériel et les dépendances tierces ; vérifiez-les au moyen d’un pilote et de tests de charge avant de vous engager sur un objectif de production.
Objectifs de capacité et de performance
| Objectif | Valeur et hypothèse |
|---|---|
| Latence de lecture du catalogue | p95 inférieur à 150 ms au niveau de l’API, en supposant que les données fréquemment consultées se trouvent dans Redis et que la base de données est sur le même réseau privé. |
| Création de commande | p95 inférieur à 400 ms, réservation du stock comprise, sur une base primaire unique dont les tables de commandes sont indexées sur (site_id, status, created_at). |
| Pic de vente flash | Parcours de commande dimensionné pour quelques milliers de requêtes par minute et par SKU via une décrémentation atomique Redis avant le règlement MySQL. Au-delà, une admission fondée sur une file d’attente est ajoutée — le seuil est confirmé par des tests de charge sur votre volume réel de données. |
| Callback de paiement | Traité de manière idempotente dans la fenêtre de nouvelle tentative de la passerelle ; les callbacks en double sont rejetés grâce à l’identifiant de transaction unique de la passerelle. |
Ce que comprend la livraison
- Sources du mini-programme, du backend Go et de l’administration Vue dans votre dépôt
- Schéma de base de données avec migrations, justification des index et documentation des tables de registre
- Documentation API couvrant l’authentification, les codes d’erreur et les exigences d’idempotence
- Notes de déploiement pour Linux, Docker et Nginx, ainsi que procédure de sauvegarde et de restauration
- Assistance à l’intégration des comptes de paiement et de messagerie ; le résultat de la revue de la plateforme reste du ressort de WeChat ou de Douyin
Planifier cela pour votre activité
Les modules ci-dessus constituent un point de départ, et non un package fixe. Nous réduisons généralement la première version à un parcours principal plus un parcours d’administration, puis nous l’étendons lorsque l’usage réel montre où se situent effectivement la charge et les cas limites. Envoyez une demande détaillée et nous la confronterons à cette architecture afin de vous indiquer quelles parties ne sont pas encore nécessaires.
