Aller au contenu

Application web • Mobile • Commerce

Place de marché internationale

Une architecture de place de marché évolutive, conçue pour gérer annonces, organisations, abonnements et expansion internationale.

Secteur
Place de marché

L'interface montrée est une représentation de l'architecture décrite ici, pas une capture d'écran client.

Enjeu

Le problème

La plateforme existante avait été bâtie pour un seul marché et un seul type de vendeur. Ajouter des organisations, des paliers d'abonnement ou une deuxième devise imposait à chaque fois des modifications dans toute la base de code, rendant l'expansion lente et risquée.

Objectifs

  • Gérer plusieurs organisations avec leurs propres utilisateurs et permissions
  • Traiter abonnements, renouvellements et états de facturation de façon fiable
  • Fonctionner sur plusieurs devises et régions
  • Faire de l'ajout d'un marché une tâche de configuration plutôt qu'un projet de développement
Approche

Comment nous l'avons traité

  • Modèle multi-locataire

    Les organisations sont devenues un concept de premier rang dans le modèle de données plutôt qu'un indicateur greffé sur les comptes utilisateurs.

  • La facturation comme automate à états

    Les états d'abonnement et leurs transitions ont été modélisés explicitement, pour que les cas limites comme un renouvellement échoué se comportent de façon prévisible.

  • Architecture de localisation

    Devise, fiscalité et langue du contenu ont été séparées, si bien qu'un marché peut être ajouté sans toucher à la logique métier.

  • Une infrastructure pour la croissance

    Déploiement, cache et observabilité ont été conçus pour un trafic régional plutôt qu'en supposant une seule région.

Design

Démarche de conception

Trois publics distincts, acheteurs, vendeurs et administrateurs, avaient besoin d'interfaces réellement différentes sur des données partagées. Une bibliothèque de composants commune les a gardées cohérentes sans les enfermer dans la même mise en page.

Technologies

  • Next.js
  • Node.js
  • PostgreSQL
  • Redis
  • Payment provider integration
  • AWS

Considérations de sécurité

  • Isolation stricte des locataires : aucune organisation ne peut atteindre les données d'une autre
  • Flux de paiement conçus pour que les données de carte soient traitées par le prestataire
  • Protection de l'interface d'administration et séparation des privilèges
  • Tests d'autorisation au niveau des objets pour les trois types d'utilisateurs
Résultat

Ce que nous avons livré

Une place de marché où organisations, abonnements et régions sont modélisés comme des concepts de premier rang, de sorte que la croissance relève de la configuration plutôt que d'un projet d'ingénierie.

Résultats

  • Nouveaux marchés ajoutés par configuration plutôt que par modification du code
  • Cas limites d'abonnement traités par un modèle d'états explicite
  • Isolation des locataires vérifiée par des tests de contrôle d'accès
  • Bibliothèque de composants partagée entre les interfaces acheteur, vendeur et administrateur

Les résultats décrivent des capacités livrées. Nous ne publions de chiffres mesurés que lorsque le client a fourni les données et approuvé leur usage.

Vous construisez quelque chose de similaire ?

Dites-nous où vous en êtes et ce qui devra être vrai à la fin. Nous reviendrons avec une approche.