Skello Tech Team
Published in

Skello Tech Team

Pourquoi un microservice n’est pas toujours la bonne réponse

Skello est une solution de pilotage RH pour tous les établissement dont les plannings sont complexes. Le cœur de métier est centré autour de ce qu’on appelle des Shifts de travail.

Ici, Jean-Pierre travaille en Salle dans un restaurant de 08h à 16h, sans pause, c’est à dire 8h consécutives.

C’est contraire à sa convention collective qui lui permet un temps de pause d’au moins 20 min après 6h de travail.

Skello affiche donc une information dans un petit tooltip lié au Shift que nous appelons une Alerte :

Notre technologie automatise la création de plannings, en prenant en compte des facteurs propres à chaque secteur (conventions collectives, contraintes légales…) et chaque employé (type de contrat, absence, congés…)

Fonctionnement initial

  • A chaque création, modification, suppression d’un Shift sur une semaine de travail, des callbacks modèles vont recalculer pour chaque Shift si il est nécessaire d’afficher une alerte (il peut y avoir plusieurs alertes cumulées)
  • Chaque alerte calculée est stockée en base de données
  • A l’affichage du planning, le frontend récupère toutes les données concernant les alertes des shifts (cela peut concerner une cinquantaine d’employés)
  • Les alertes peuvent cibler des périodes, par exemple ici , l’employé ne doit pas travailler plus de 6 jours consécutifs :

💡 Les alertes de shifts est une des fonctionnalités les plus gourmandes en ressources chez Skello (calculs serveur (ruby), i/o sur la DB, nombreuses requêtes aux contrôleurs associées).
Nous avons en base de données plusieurs dizaines de millions de Shifts et donc encore plus d’entrées correspondantes à ces alertes.

Cette solution technique est difficile à maintenir et à scaler.

Envisageons un microservice

Dans le but d’externaliser toute cette logique et d’alléger la base de données, nous pourrions être tenté de mettre en place une architecture basée sur un microservice :

Cette solutions nous permettrait de scaler facilement, de mieux maîtriser le code soutenant les calculs et de répartir la charge sur les bases de données.

Solution retenue

AUCUN MICRO-SERVICE

La solution retenue est venue de la réflexion que l’application front Skello possède déjà beaucoup de données pour afficher le planning (Employés, les Shifts de travail …), ces même données dont nous avons besoin pour calculer des Alertes !

Nous avons décidé de déporter cette logique dans le code frontend de l’application, ce sera donc aux navigateurs web des clients de faire tourner le code de calcul et d’affichage des alertes

Vous-vous direz peut-être : “C’est évident” 💡

Présenté comme cela peut-être, mais la difficulté était de sortir du paradigme qui avait été mis en place initialement à la création du projet, à une époque où il n’y avait ni problème de volumes ni soucis de performances car un peu moins de clients.

Implémentation de la solution

Nous avons développé un package nodeJS, qui va embarquer les règles de calcul des Alertes, qui prendra en entrée les données nécessaire au calculs et renverra les informations nécessaire pour afficher les bonnes Alertes sur les Shifts :

Cette solution a pour avantage que si nous devons mutualiser ces calculs, il sera alors possible d’importer ce package dans une lambda ou dans notre app mobile (développée en react native).

Les microservices ne sont pas la solution à tout. Gardons toujours en tête le principe KISS.

Alexandre, Full stack développeur Sénior — Skello Tech Team

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store