Backend e-commerce Java Spring : authentification JWT, commandes et cache Caffeine

Table des matières :

1. Cadrage technique : stack Spring, périmètre API et contraintes e-commerce
2. Authentification JWT sous Spring Security : flux, signatures, révocation et erreurs fréquentes
3. Commandes : modélisation, idempotence checkout et concurrence (stocks, paiements)
4. Cache Caffeine : quand l’utiliser, comment le configurer, et comment mesurer l’impact
5. Architecture multi-instance : cohérence cache, invalidation et placement des responsabilités
6. Intégration e-commerce (PrestaShop/headless), exploitation et tests : ce qui évite les incidents

Un backend e-commerce en Java Spring qui tient en production, ce n’est pas « juste » exposer des endpoints. Les trois points qui cassent en premier sous charge réelle sont (1) la gestion d’authentification/autorisation, (2) la cohérence transactionnelle des commandes, et (3) la stratégie de cache (locale vs distribuée) — avec des impacts directs sur le TTFB, les timeouts et les erreurs de concurrence.

Dans un contexte e-commerce, les symptômes arrivent vite et se ressemblent : latence qui explose sur POST /orders, pics de 401/403 parce que les JWT expirent en plein checkout, et « stock négatif » lors d’une campagne (soldes, Black Friday) parce que deux transactions se marchent dessus. L’objectif est donc de concevoir un chemin critique (auth → panier/checkout → paiement → commande) qui reste stable quand tout le reste devient instable.

Cadrage technique : stack Spring, périmètre API et contraintes e-commerce

Pour fixer un cadre reproductible, on part sur Java 21 (LTS), Spring Boot 3.3+ (Spring Framework 6.1+) et Spring Security 6. L’enjeu principal en 2026 n’est plus « est-ce que ça compile », mais comment ça se comporte derrière un reverse-proxy, en multi-instance, avec des pics de trafic. Si vous êtes dans un contexte PrestaShop/headless, la frontière est nette : votre backend Spring devient soit un BFF (Backend For Frontend), soit un microservice « commande/paiement » derrière une API Gateway.

Quelques contraintes e-commerce typiques à figer dès le départ (sinon vous les paierez en production) :

• SLO latence et erreurs sur le chemin critique : p95/p99 sur GET /catalog, POST /orders, callbacks paiement, et taux de 409/422/5xx.
• Règles de TVA et expédition dépendantes du pays (ex. France : TVA standard 20% ; certains produits/territoires peuvent diverger), donc un modèle qui accepte la variabilité sans tout recoder.
• RGPD : minimiser les données personnelles en logs (éviter email/nom/adresse en clair), tracer via identifiants techniques (customerId, orderId, traceId) plutôt que PII.
• Pics courts mais violents : davantage de contention DB, plus de retries réseau, et plus d’erreurs « transitoires » qui déclenchent des relances côté client/PSP.

Côté edge, ne négligez pas ce que vous externalisez : terminaison TLS, rate limiting, WAF, logs corrélables. À ce sujet, l’article interne sur API Gateway (authentification, rate limiting, routage) fournit un cadre de conception utile : lire l’article. Si vous êtes plutôt reverse-proxy « classique », une config HAProxy durcie (TLS, ACL, supervision) est plus réaliste qu’un API manager lourd : lire l’article HAProxy.

Deux points pratiques (souvent oubliés) derrière proxy / K8s :

• Forward headers : configurez correctement X-Forwarded-For / X-Forwarded-Proto pour que Spring reconstruise des URLs cohérentes, et pour que vos logs et règles sécurité (CORS, redirect) ne soient pas « faux » en production.
• Timeouts réalistes : timeouts trop longs côté gateway masquent les problèmes et amplifient les retries ; timeouts trop courts déclenchent des doubles commandes. L’alignement gateway ↔ client ↔ serveur ↔ DB est une décision produit autant que technique.

Enfin, définissez ce que vous cachez, et où. Caffeine est un cache in-process : ultra-performant, mais non partagé entre pods/VM. Dès que vous scalez horizontalement, vous devez accepter une cohérence « best-effort » (TTL + invalidation) ou introduire un cache distribué (Redis). Pour la vision « multi-niveaux » (Varnish/Redis/OPcache) et les pièges de cohérence, vous pouvez recycler la logique décrite côté PrestaShop : lire l’article sur le cache (les principes s’appliquent pareil, même si le runtime change).

Authentification JWT sous Spring Security : flux, signatures, révocation et erreurs fréquentes

JWT n’est pas un buzzword, c’est un format. La définition normative est claire : RFC 7519 (IETF) : “JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.” (RFC 7519, Abstract) — spécification RFC 7519. La conséquence technique : si vous mettez des claims dedans, tout ce qui est dans le payload est lisible (base64url ≠ chiffrement). Le seul garant est la signature (JWS) ; le chiffrement (JWE) est un autre sujet, plus rare en API publique.

En Spring moderne, l’implémentation la moins « bricolage » consiste à se comporter en Resource Server avec validation JWT. Spring Security rappelle son rôle : “Spring Security is a powerful and highly customizable authentication and access-control framework.” — projet Spring Security. Concrètement : vous validez iss, aud, exp, l’algorithme (alg) attendu, et vous mappez les claims vers des authorities. Le piège classique : accepter plusieurs algos, ou pire, accepter none/mauvais kid ; imposez un set strict.

Au niveau e-commerce, quelques conventions de claims évitent beaucoup d’ambiguïtés :

• sub : identifiant utilisateur (ou client) stable côté IAM.
• scope / scp : scopes (orders:read, orders:write, etc.) plutôt que des rôles « fourre-tout ».
• aud : audience (utile si vous avez plusieurs APIs/microservices).
• jti : identifiant unique du token (utile pour révocation/anti-replay).
• exp + gestion de dérive d’horloge : un léger clock skew existe toujours entre machines.

Exemple minimal (Spring Boot 3.x) :

@Configuration
@EnableWebSecurity
public class SecurityConfig {

  @Bean
  SecurityFilterChain security(HttpSecurity http) throws Exception {
    return http
      .csrf(csrf -> csrf.disable())
      .sessionManagement(sm -> sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
      .authorizeHttpRequests(auth -> auth
        .requestMatchers("/actuator/health", "/v1/auth/**").permitAll()
        .requestMatchers(HttpMethod.POST, "/v1/orders").hasAuthority("SCOPE_orders:write")
        .requestMatchers(HttpMethod.GET, "/v1/orders/**").hasAuthority("SCOPE_orders:read")
        .anyRequest().authenticated())
      .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()))
      .build();
  }
}

Erreurs fréquentes observées en prod (et comment les rendre « actionnables ») :

• 401 vs 403 : 401 = token absent/invalide/expiré ; 403 = token valide mais scope insuffisant. Séparez les métriques (sinon vous « voyez » un problème auth indistinct).
• Mauvaise audience : token émis pour un autre service → mieux vaut refuser strictement et loguer aud, iss, kid (sans loguer le token entier).
• CORS trop permissif : surtout en BFF. Si l’API est consommée par un front précis, verrouillez les origines et méthodes.

La « vraie vie » impose deux sujets supplémentaires : révocation et rotation des clés. Un JWT stateless se révoque mal. Pour un e-commerce, c’est problématique (compte compromis, logout, changement de mot de passe, etc.). Les approches réalistes : (a) access tokens très courts + refresh token côté serveur, (b) liste de révocation (JTI) stockée en Redis avec TTL, (c) introspection OAuth2 (donc token opaque).

Un mini-scenario typique où ça casse : un client déclenche un checkout, puis change son mot de passe (ou un support force une réinitialisation). Si vous n’avez aucun mécanisme de révocation, l’ancien JWT reste valide jusqu’à exp. En e-commerce, ça peut suffire à passer commande malgré une action censée « couper » la session.

Si vous partez sur Redis pour gérer les JTIs, alignez-vous sur des patterns de sécurisation (bind, ACL, TLS, monitoring) : guide Redis en production.

Commandes : modélisation, idempotence checkout et concurrence (stocks, paiements)

La commande est un agrégat qui combine pricing, taxes, livraison, paiements, et surtout des invariants : une commande validée ne doit pas « reculer » d’état sans trace. La difficulté dans Spring n’est pas JPA en soi, c’est d’imposer une logique métier transactionnelle et auditable. En pratique : une création de commande doit être encapsulée dans une transaction DB (PostgreSQL ou MySQL), avec des contraintes explicites (FK, unique index), et des verrous choisis (optimistic/pessimistic) selon la pression concurrentielle.

Un point souvent sous-estimé : formaliser les transitions d’état (et les bloquer en base / au service). Même sans moteur de state machine, un tableau simple clarifie la logique et évite les « états impossibles » :

État	Évènement entrant	État suivant attendu	Notes
CREATED	paiement autorisé	PAID	tracez l’ID transaction PSP
CREATED	paiement refusé	PAYMENT_FAILED	ne jamais repasser à CREATED
PAID	préparation	FULFILLING	stock déjà confirmé
FULFILLING	expédition	SHIPPED	numéro de suivi
SHIPPED	livraison	DELIVERED	selon le transporteur
PAID / FULFILLING	annulation	CANCELLED	via compensation, pas suppression

Côté base, les garde-fous « simples » font une vraie différence : index uniques sur les identifiants métier, contraintes de non-null, et un mécanisme d’audit (timestamps, createdBy, lastModifiedBy) si vous avez un back-office.

Le second sujet qui fait doublonner les commandes : retries réseau (frontend, PSP, gateway). Votre endpoint POST /orders doit être idempotent au niveau métier. Le pattern standard : un header Idempotency-Key (UUID) + enregistrement atomique (table idempotency_keys avec unique index sur {customer_id, key}) + retour du même résultat si on rejoue. Sans ça, vous aurez des « doubles commandes » lors des timeouts, et vous passerez votre temps à nettoyer.

Deux détails pratiques pour que l’idempotence survive à la production :

• Stockez le résultat (ou au moins l’orderId) avec une TTL raisonnable (ex. quelques heures/jours selon votre UX). L’objectif est de couvrir les retries et le « double clic », pas de conserver une table infinie.
• Appliquez la même logique aux webhooks PSP (paiement) : les prestataires renvoient des callbacks en doublon, parfois minutes/heures après, et parfois dans le désordre.

Exemple de squelette (service transactionnel) :

@Service
public class OrderService {

  private final OrderRepository orderRepository;
  private final IdempotencyRepository idempotencyRepository;

  @Transactional
  public OrderCreatedDto createOrder(CreateOrderCommand cmd, UUID idemKey, long customerId) {
    var existing = idempotencyRepository.findResult(customerId, idemKey);
    if (existing.isPresent()) {
      return existing.get();
    }

    // 1) recalcul pricing côté serveur (ne faites pas confiance au client)
    // 2) réservation stock (optimistic lock ou réservation via table dédiée)
    // 3) persistance Order + lignes

    Order order = Order.from(cmd, customerId);
    orderRepository.save(order);

    OrderCreatedDto result = new OrderCreatedDto(order.getId(), order.getStatus());
    idempotencyRepository.storeResult(customerId, idemKey, result);
    return result;
  }
}

Sur la concurrence stock, évitez les « décréments naïfs ». Deux patterns dominent : (1) optimistic locking sur une ligne stock (versioning), (2) réservation temporaire (hold) avec TTL, confirmée au paiement.

• L’optimistic locking marche bien si la contention est modérée : en cas de collision, vous retry quelques fois (avec backoff) et vous retournez un 409 si impossible.
• La réservation temporaire est plus robuste en pic (flash sales), mais demande une mécanique d’expiration et un job de nettoyage (ou une table de holds avec expires_at).

Si vous êtes déjà dans une logique Redis pour anti-concurrence, l’approche « lock/atomic decrement + compensation » peut fonctionner, mais elle doit être documentée et testée (sinon vous créez des stocks négatifs). Sur ce thème, l’article interne « prévenir la concurrence sur les stocks avec Redis » donne des axes concrets : lire l’article.

Enfin, ne confondez pas « transaction DB » et « transaction métier complète » : dès que vous parlez paiement, email, ERP, transporteur, vous êtes en distribué. Une technique pragmatique est de persister votre commande + un évènement « à publier » dans la même transaction (pattern outbox), puis de publier ensuite. L’objectif n’est pas la perfection théorique, mais de réduire drastiquement les « commandes payées mais non confirmées » (ou l’inverse).

Cache Caffeine : quand l’utiliser, comment le configurer, et comment mesurer l’impact

Caffeine est un cache local (heap JVM) très efficace. Le projet le décrit sans ambiguïté : “Caffeine is a high performance, near optimal caching library.” (README Caffeine) — page GitHub Caffeine. En pratique, il implémente des politiques modernes (W-TinyLFU) et expose des stats utiles. Sur un backend e-commerce, ça sert surtout pour des lectures fréquentes et peu volatiles : règles de livraison, mapping de catégories, paramètres de taxation, configuration boutique, feature flags, ou « read models » projetés.

Sous Spring, le point important est de choisir vos TTL/taille en fonction des SLO et pas « au pif ». Exemple : une ressource consultée 5 000 fois/minute et recalculée en 15 ms, c’est un candidat évident pour réduire le CPU et le p95. À l’inverse, cacher des réponses dépendantes du contexte (prix client, promotions dynamiques, disponibilité stock) vous donne des bugs de cohérence difficiles à reproduire. Caffeine ne remplace pas un cache HTTP ni un cache distribué ; c’est un accélérateur local.

Quelques cas concrets où Caffeine apporte souvent un vrai gain (sans casser le métier) :

• Référentiels à faible churn : pays, transporteurs, zones, règles de TVA « de base ».
• Configuration boutique : seuil de livraison offerte, options d’affichage, feature flags internes.
• Read model côté API : par exemple un CatalogReadModel pré-assemblé (catégorie → liste de produits) si vous maîtrisez l’invalidation.

Et quelques anti-patterns classiques :

• Cacher des données « vivantes » comme stock ou prix personnalisé sans clé incluant le contexte (client, groupe, devise, canal).
• Utiliser un TTL long « pour la perf » sans stratégie d’invalidation : vous gagnez du p95, mais vous perdez la confiance métier (promos qui n’apparaissent pas, TVA erronée, etc.).

Configuration typique avec stats + bornage :

@Configuration
@EnableCaching
public class CacheConfig {

  @Bean
  public Caffeine<Object, Object> caffeineSpec() {
    return Caffeine.newBuilder()
      .maximumSize(50_000)
      .expireAfterWrite(Duration.ofMinutes(5))
      .recordStats();
  }

  @Bean
  public CacheManager cacheManager(Caffeine<Object, Object> caffeine) {
    var mgr = new CaffeineCacheManager("shippingRules", "taxRules", "catalogReadModel");
    mgr.setCaffeine(caffeine);
    return mgr;
  }
}

Et côté usage, imposez des clés stables et explicites (évitez les objets complexes en key implicite) :

@Cacheable(cacheNames = "taxRules", key = "#countryIso")
public TaxRuleSet loadTaxRules(String countryIso) {
  return repository.findByCountry(countryIso)
    .orElseThrow();
}

Deux leviers souvent utiles quand vous commencez à mesurer :

• Séparer les caches par domaine (taxes vs livraison vs read model) pour éviter qu’un cache « bruyant » évince tout.
• Si vos valeurs sont très hétérogènes en taille, préférer un bornage par poids (maximumWeight) plutôt qu’un simple maximumSize (sinon quelques entrées lourdes suffisent à dégrader l’ensemble).

Pour ne pas piloter à l’aveugle, exposez les stats via Micrometer et vérifiez le couple (hit rate, eviction count) ainsi que le gain en latence. Un cache « performant » avec un hit rate à 5% est un cache inutile, et un cache avec un hit rate à 98% mais des invalidations manuelles oubliées vous crée des erreurs fonctionnelles.

Checklist rapide (pratique en runbook) :

• Quel est le propriétaire métier de la donnée cachée (qui décide « c’est ok si ça a 2 minutes de retard ») ?
• Quel est le TTL et pourquoi (évènement externe, fréquence de mise à jour, risque utilisateur) ?
• Quel est le plan d’invalidation (admin change → @CacheEvict, pub/sub, ou TTL only) ?
• Que se passe-t-il au cold start (déploiement, scaling) : DB prend-elle le pic de cache miss ?

Si vous avez déjà une discipline de monitoring/alerting côté e-commerce, appliquez la même rigueur : l’approche « tests de charge + runbooks » décrite ici est transposable : lire l’article.

Architecture multi-instance : cohérence cache, invalidation et placement des responsabilités

Dès que vous avez plus d’une instance applicative, Caffeine devient incohérent par design : chaque nœud a sa propre vue. Pour un catalogue, ce n’est pas toujours grave (TTL court). Pour des règles de prix/promo, ça peut être critique. Deux stratégies réalistes : (1) accepter la cohérence éventuelle avec TTL + « cache stampede protection » (par ex. @Cacheable(sync = true) sur certaines méthodes), (2) introduire une invalidation par évènement (Kafka/RabbitMQ) ou par pub/sub (Redis), chaque instance purgeant ses caches locaux.

Le stampede (effet troupeau) est un vrai sujet en e-commerce : au moment où un TTL expire, 20 pods peuvent retaper la DB en même temps. Pour les endpoints à très forte fréquence, combinez :

• un TTL pas trop long (cohérence),
• une protection contre recalcul concurrent,
• et, si nécessaire, un mécanisme de pré-chauffage lors des déploiements (ex. charger les règles de livraison/TVA les plus consultées au démarrage, mais uniquement si vous maîtrisez la charge DB au boot).

Si vous devez partager de la donnée cachée (sessions, révocation JWT, read models partagés), un cache distribué est souvent plus simple. Redis reste le standard pragmatique en e-commerce. Attention : ce n’est pas magique non plus (pannes, latence réseau, taille mémoire, persistance). Avant de « tout mettre dans Redis », lisez une config de prod propre : guide Redis.

Caffeine et Redis ne sont pas en concurrence : le pattern efficace est souvent L1 = Caffeine (très rapide, TTL court) + L2 = Redis (partagé, TTL plus long), avec invalidation contrôlée. Concrètement, ça vous permet :

• de réduire la latence moyenne (L1),
• de réduire les divergences inter-instances (L2),
• tout en gardant un mode dégradé : si Redis est lent/indisponible, votre service peut (selon les cas) retomber sur la DB plutôt que tomber en panne sèche.

Enfin, évitez de mélanger sécurité et cache. Ne cachez pas des réponses contenant des données personnelles sans clé incluant le scope utilisateur, et maîtrisez vos headers HTTP. Même si l’article interne vise PHP, la logique des HTTP Security Headers (CSP/HSTS, etc.) rappelle une chose importante : la sécurité n’est pas « dans le code », elle est aussi dans la config HTTP : guide HTTP Security Headers. Pour une API, vous allez plutôt pousser HSTS, X-Content-Type-Options, et des règles CORS strictes au niveau gateway.

Intégration e-commerce (PrestaShop/headless), exploitation et tests : ce qui évite les incidents

Si vous intégrez ce backend à PrestaShop, choisissez votre surface : (a) consommer le Webservice PrestaShop pour synchroniser des ressources (produits, clients), ou (b) viser l’API d’admin (PrestaShop 9) si vous êtes sur cette base. Les deux articles internes posent les prérequis et les limites : Webservice PrestaShop et API d’administration PrestaShop 9.

Dans un modèle hybride, votre service « orders » Spring peut gérer un checkout custom, puis pousser l’état dans PrestaShop (ou inversement). Documentez l’autorité de vérité : sinon vous aurez des divergences impossibles à réconcilier. Un exemple classique : PrestaShop applique une règle de promo différente de votre service (même si l’écart est de quelques centimes), et le support se retrouve avec des commandes « incohérentes » à expliquer. La solution n’est pas seulement technique : c’est une décision d’architecture (où vit le pricing final ?) et une stratégie de reconciliation (job quotidien, alertes sur écarts).

En exploitation, la discipline est simple : logs structurés, corrélation (traceId), métriques p95/p99, et alertes sur erreurs applicatives (401/403, 409, 5xx) + saturation ressources. Une règle utile : toute action client « visible » (connexion, paiement, création commande) doit produire un log corrélable et une métrique (sinon vous ne pouvez pas distinguer bug, fraude, ou incident infra).

Si vous n’avez pas de base, reprenez une logique de « diagnostic/ressources » (logs, saturation) équivalente à celle détaillée pour les HTTP 503 : diagnostic HTTP 503. Ce n’est pas spécifique à PrestaShop : un pool DB saturé ou un thread pool épuisé côté Spring produit exactement les mêmes symptômes.

Enfin, testez ce que vous croyez avoir sécurisé. Un backend JWT + cache local + endpoints commande doit être soumis à : (1) tests de charge (latence p95 et débit), (2) tests de résistance (pannes Redis/DB, redéploiement), (3) tests de sécurité (alg JWT, claims, CORS, rate limit, brute force).

Une façon simple de rendre ça concret est de définir 3 campagnes de tests qui collent au réel :

• Campagne “soldes” : trafic lecture (catalogue) + pic création commande + montée en charge progressive (observer DB, cache hit rate, 409 stocks).
• Campagne “panne partielle” : Redis indisponible 2 minutes (revocation JWT, idempotency si vous y dépendez), puis retour (vérifier rattrapage, timeouts).
• Campagne “déploiement” : rolling update multi-instance (cache cold, clés JWT rotation), vérifier que l’expérience reste stable.

Sans ça, vous allez découvrir en production que votre TTL Caffeine masque un problème SQL, ou que votre idempotence ne couvre pas les callbacks PSP. Si vous faites du hardening infra, gardez aussi un œil sur les compatibilités et exigences des briques (DB, search, etc.) : la rigueur « exigences système minimales » est une bonne habitude, même hors PHP : exigences système minimales.