Comment la plate-forme à 208 modules de Mewayz reste rapide, flexible et ne tombe jamais en panne

La salle des machines : pourquoi l'architecture est importante à grande échelle

Créer une application métier unique est difficile. Construire une plate-forme cohérente avec 208 modules distincts (du CRM à la facturation en passant par la gestion et l'analyse de flotte) est un défi d'ingénierie d'une autre ampleur. Chez Mewayz, notre architecture technique n'est pas qu'un détail d'implémentation ; c'est la promesse principale du produit. C'est ce qui permet à une startup bénéficiant de notre offre gratuite de gérer la paie parallèlement à son CRM, et à une entreprise de 5 000 employés de mettre en marque blanche l'ensemble de la plateforme, le tout sans dégradation des performances. Pour nos plus de 138 000 utilisateurs dans le monde, l'architecture est invisible, mais son impact se ressent chaque jour dans la rapidité, la fiabilité et la flexibilité de la plateforme. Il s’agit d’un aperçu des principes et des technologies qui rendent cela possible.

La philosophie de base : microservices et contextes délimités

Notre décision fondamentale était d’éviter à tout prix une base de code monolithique. Une application unique et tentaculaire tentant de gérer les ressources humaines, la comptabilité et la gestion de projet deviendrait un cauchemar à maintenir, à mettre à jour et à faire évoluer. Au lieu de cela, nous avons construit Mewayz sur une architecture de microservices stricte. Chacun de nos 208 modules est un service indépendant et autonome. Le module Facturation possède sa propre base de données, sa propre logique et son propre code. Le module de gestion de flotte est entièrement distinct. Ils ne partagent pas de base de données et n’appellent pas directement les fonctions internes de chacun.

Cette approche, connue sous le nom de définition de « contextes délimités », est cruciale. Cela signifie que nos équipes de développement peuvent travailler sur le module Réservation et publier une mise à jour sans aucune dépendance ni risque pour le module Paie. C'est ainsi que nous pouvons innover rapidement. Le compromis, bien sûr, est la complexité de la communication entre ces services, que nous résolvons avec notre prochain composant principal.

Le système nerveux : communication événementielle

Si les microservices sont les organes de la plateforme, la communication événementielle en est le système nerveux central. Au lieu que les services effectuent des appels API directs les uns aux autres (ce qui crée un couplage étroit et peut conduire à des pannes en cascade), les services communiquent en émettant et en écoutant des événements. Par exemple, lorsqu'une affaire de vente est marquée « Fermée-Won » dans le module CRM, elle n'appelle pas directement le module Facturation. Au lieu de cela, il publie un événement : deal.closed.won. Le service Facturation, abonné à cet événement, le récupère automatiquement et crée un nouveau projet de facture. Le CRM n'a pas besoin de savoir si le service de facturation est actif, inactif ou lent.

Cette architecture offre une immense résilience et évolutivité. Si le service de facturation est temporairement indisponible, l'événement reste dans une file d'attente jusqu'à ce qu'il revienne en ligne. Il permet également des flux de travail puissants et découplés. Le module RH peut également écouter deal.closed.won pour déclencher un calcul de commission pour le commercial, le tout sans que le CRM ait besoin de connaître les processus RH. Nous utilisons un courtier de messages robuste (Apache Kafka) pour garantir que ces événements sont durables et livrés dans l'ordre.

Souveraineté des données et passerelle API

Avec des données réparties dans des centaines de bases de données de microservices, comment présenter une vue des données unifiée et sécurisée à l'utilisateur final ? C'est le travail de notre API Gateway. Il agit comme un point d'entrée unique et sécurisé pour toutes les demandes des clients, qu'elles proviennent d'un navigateur Web, d'une application mobile ou d'une intégration tierce via notre API publique. La passerelle gère l'authentification, la limitation du débit et le routage des demandes.

Lorsque vous affichez un tableau de bord client qui affiche son dernier projet (module de projet), une facture impayée (module de facturation) et des tickets d'assistance (module CRM), la passerelle API est l'orchestrateur. Il prend la requête unique, la diffuse vers les microservices concernés, regroupe les réponses et renvoie un objet JSON cohérent au client. Ce modèle garantit que les données restent dans leur contexte délimité tout en offrant l'expérience unifiée attendue par les utilisateurs.

La colle qui lie : notre API publique et notre stratégie en marque blanche

Notre API à 4,99 $ par module n'est pas une réflexion secondaire ; c'est un citoyen de première classe alimenté par le même système interne

Frequently Asked Questions

What is the biggest advantage of a microservices architecture for a business platform?

The biggest advantage is independent scalability and development. Teams can update, deploy, and scale individual modules like CRM or Payroll without affecting the stability or performance of the rest of the platform.

How does Mewayz prevent data leaks between different companies using the platform?

We use a strict multi-tenant design where every row in our databases is scoped with a `tenant_id`. This ensures that a query for one company's data can never accidentally access another's, providing a fundamental layer of security.

If a module goes down, does it take the whole platform with it?

No. Because modules are isolated microservices, the failure of one (e.g., the Booking module) does not cascade. Other modules remain fully operational, and the failed module's functions can often be queued until it recovers.

How does the white-label feature work technically?

White-labeling is possible because our presentation layer (the UI) is completely separate from our backend microservices. Partners can rebrand the front-end client, which communicates with our unified API, without touching the core business logic.

Is the public API the same as what the Mewayz web app uses?

Yes. Our public API and web app both connect through the same API Gateway to the same backend microservices. This ensures consistency, reliability, and that new features are available via the API immediately.