Ticket reçu :
« L’API est trop lente. »
Pas de trace dans les logs applicatifs.
Pas d’erreur apparente.
Pas de détail côté client.
Juste un retour flou et une attente de solution rapide.
J’analyse. Je reproduis. J’inspecte chaque couche :
contrôleur, service, repository.
Au final, un Thread.sleep() oublié lors d’un test de charge…
passé en production par négligence.
Correction immédiate.
Service restauré.
Plus de lenteur.
Ce genre d’incident me rappelle que, côté backend, chaque détail compte.
Un oubli minime peut dégrader toute une expérience utilisateur.
Et parfois, c’est dans les zones grises celles qu’on regarde le moins que se cachent les problèmes les plus critiques.
Ce type d’expérience me pousse à renforcer mes pratiques de revue, de test, et d’observabilité.
Pas pour le prestige.
Mais pour la fiabilité.
🙌
Spring Boot & Microservices Developer | Java Back-End Engineer | Currently @ SONELGAZ SERVICE
3 months ago
Le bon vieux Thread.sleep() traînant tel un vieux sous-marin mime antipersonnel.
Plus sérieusement, cela interroge à la fois la structure de nos tests de charge et de nos pratiques de nettoyage de code pré-livraison. Une révision de ce process peut sembler salutaire.
C'est super intéressant comme approche, c'est vrai que ça peut être problématique de rajouter du temps de latence. C'est souvent pour laisser aussi le temps aux composants de travailler le code. Mais ça peut impacter l'User expérience.
Bonne approche