Synchrone ou asynchrone : sortir le travail du chemin critique
- Email ou PDF dans la requête : la page attend deux secondes pour rien.
- Déposer ces tâches dans une file traitée en arrière-plan.
- La requête répond tout de suite, le reste suit sans elle.
- Autant de travail au total, mais la latence ressentie s'effondre.
Questions fréquentes
Comment décider quels traitements basculer en asynchrone et lesquels garder dans la requête ?
Une seule question à poser, traitement par traitement : l'utilisateur a-t-il besoin du résultat pour obtenir sa réponse ? Si oui, ça reste synchrone. Sinon, direction la file. Je ne bascule jamais tout par principe ; un traitement rapide qui conditionne la page n'a rien à gagner à partir en arrière-plan, et vous y perdez en lisibilité du code. Le critère n'est pas la lenteur seule, c'est la lenteur ET l'absence de dépendance.
Faut-il forcément installer un broker (le logiciel dédié qui transporte les messages de la file) comme RabbitMQ ou Redis pour démarrer ?
Non, et c'est souvent là que les équipes se bloquent inutilement. Symfony Messenger sait écrire la file dans votre base de données existante (transport Doctrine), Laravel fait pareil avec le driver database. Vous démarrez sans nouvelle brique d'infrastructure, vous validez l'approche, et vous migrez vers Redis ou un vrai broker le jour où le débit le justifie. Commencer par RabbitMQ pour trois emails par minute, c'est se rajouter un serveur à superviser pour rien.