La marketplace affiche 2 000 visites par jour en médiane. Le jour où un vendeur star arrive en live, 80 000 sessions en trois heures font tomber la base — dimensionnée pour la moyenne, pas pour l'événement. L'équipe découvre alors que le monitoring mensuel lissé masquait des bursts horaires que le dimensionnement infrastructure n'avait jamais anticipés.
Une marketplace concentre des pics corrélés : lancement produit, influenceur, soldes, publicité télévisée. L'hébergement doit être pensé pour le p95 ou p99 du trafic, pas pour la feuille de calcul mensuelle. Le pic n'est pas une anomalie — c'est le modèle économique.
Pourquoi la moyenne ment
Les visites journalières moyennes masquent des bursts horaires. Le processeur moyen reste bas puis explose au checkout. Le coût infra « au quotidien » oublie la facture cloud du jour de lancement. Un graphique Analytics lissé rassure ; un test charge sur le parcours paiement accuse.
| Métrique | Piège |
|---|---|
| Visites/jour moyennes | Cache les pics d'une heure |
| CPU moyen | Au repos puis saturation au paiement |
| Budget infra quotidien | Oublie le jour à cinquante fois le trafic |
Architecture minimale scalable
L'application doit rester sans état pour monter horizontalement derrière un load balancer. Un CDN sert assets, images produits et pages catalogue cacheables. Redis ou Memcached cache sessions et listings chauds. Une file d'attente traite e-mails, indexation recherche et webhooks vendeurs de façon asynchrone. La base managée avec sauvegardes et réplica en lecture se prépare avant le pic — pas le jour J.
Évitez un monolithe sur un VPS sans plan B. Le guide budget hébergement aide à chiffrer le coût du pic, pas seulement le coût médian.
Scénarios de pic à modéliser
Simulez une vente flash d'un vendeur — dix fois le trafic en une heure. Un Black Friday global — cinquante fois le checkout. Un crawl massif après indexation Google. Des uploads groupés côté vendeurs — charge disque et IO. Testez chaque scénario ; tester uniquement la homepage est une illusion de sécurité.
Côté contrat, lisez le SLA : auto-scaling, limites connexions base, crédits versus chiffre d'affaires perdu. Évaluez le support avant le gros jour via le comparateur.
Le sommet : le premier pic révèle l'architecture
Guides liés : SaaS multi-tenant, média vidéo si le catalogue est riche en médias.
Décider et avancer sans angle mort
Mesurez les pics historiques ou simulez conservativement un événement vendeur avant de signer l'infra. Construisez une architecture avec montée en charge, cache et file d'attente — pas un VPS unique sans réplica. Lancez un test de charge sur le checkout complet avant lancement public. Budgétez explicitement le jour de pic cloud et des alertes de facturation. Rédigez un runbook incident et un plan de communication vendeurs pour le jour où la file d'attente dépasse trente secondes.
Questions fréquentes
Quel hébergement pour une marketplace early stage ?
Un cloud avec montée en charge horizontale sur l'application, une base managée, un CDN pour les assets et une file d'attente pour les tâches lourdes. Évitez le mutualisé ; un VPS seul casse souvent au premier pic vendeur.
Faut-il dimensionner sur le trafic moyen ?
Non. Dimensionnez sur le pic prévisible — soldes, lancement — avec une marge de 30 à 50 %. Le trafic moyen sous-estime toujours les événements marketplace.
Base de données : le goulot d'étranglement ?
Souvent oui. Réplicas en lecture, cache Redis, indexation et séparation lecture/écriture avant le pic. Testez la charge sur le parcours checkout, pas seulement la page d'accueil.
Comment tester avant un lancement ?
Utilisez k6, Locust ou équivalent sur des scénarios réalistes — navigation, panier, paiement. Fixez des objectifs p95 de latence et de taux d'erreur — croisez avec budget et SLA.
La prochaine fois qu'on dimensionnera sur la médiane, simulez le jour où un vendeur envoie sa liste mail. C'est généralement ce jour-là que l'infrastructure décide.