Files d'attente, Streams et traitement asynchrone
Dans cette leçon, on apprend comment un système gère un travail lourd sans laisser l'utilisateur attendre. L'idée : au lieu de tout faire tout de suite, on place la tâche dans une queue et on la traite en arrière-plan. On découvre les queues (files d'attente — une file d'attente de tâches, exactemen
Le System Design (la façon de concevoir un gros logiciel qui sert beaucoup de monde) est comme planifier une ville : routes, entrepôts, feux de circulation et équipes de maintenance — pour que la ville continue de bien fonctionner même aux heures de pointe les plus chargées.
- Traitement asynchrone
- Traiter le travail en arrière-plan au lieu de faire attendre l'utilisateur (asynchrone — « pas en même temps », c'est-à-dire qu'on n'est pas obligé de tout terminer avant de répondre). La compétence centrale de cette leçon couvre les queues (files d'attente de tâches), les streams (flux continu de messages), les retries (nouvelles tentatives en cas d'échec), l'idempotency (pour qu'un message traité deux fois ne cause aucun dommage) et le backpressure (un ralentissement contrôlé quand trop de travail arrive).
- Trade-off
- Un choix conscient qui comporte à la fois un gain et un coût — exactement comme choisir un itinéraire : la route rapide coûte un péage, la gratuite prend plus de temps. En entretien, tu expliques à la personne qui t'interviewe le gain et le coût de chaque choix.
- Métrique opérationnelle
- Un chiffre qui montre si la décision fonctionne vraiment une fois que le système est en ligne et sert de vrais utilisateurs (production). Par exemple : latency (le temps que met une réponse à arriver), error rate (la part des requêtes qui échouent), queue lag (combien de tâches attendent dans la file) et cache hit ratio (combien de fois on a trouvé une réponse déjà prête). Comme les cadrans du tableau de bord d'une voiture — ils indiquent si tout va bien.
