Laravel Distributed Systems
Queue-based communication, events, outbox pattern, idempotency, retries, circuit breaker, API contracts, versioning, saga basics
1Qu'est-ce que l'outbox pattern dans les systèmes distribués Laravel ?
Qu'est-ce que l'outbox pattern dans les systèmes distribués Laravel ?
Réponse
L'outbox pattern consiste à stocker les messages/events dans une table database lors de la même transaction que les données métier, puis les envoyer de manière asynchrone dans un processus séparé. Cela garantit que les messages sont toujours envoyés même si le système crash après le commit DB. ShouldQueueAfterCommit en Laravel est une implémentation partielle de ce pattern, car il dispatch le job seulement après commit de la transaction, évitant les race conditions où le job s'exécute avant que les données soient disponibles.
2Quelle est la différence principale entre ShouldQueue et ShouldQueueAfterCommit ?
Quelle est la différence principale entre ShouldQueue et ShouldQueueAfterCommit ?
Réponse
ShouldQueue dispatch le job immédiatement dans la queue, même si la transaction DB n'est pas encore commitée, ce qui peut causer des race conditions. ShouldQueueAfterCommit attend que toutes les transactions DB soient commitées avant de dispatcher le job, garantissant que les données sont disponibles quand le job s'exécute. Utiliser ShouldQueueAfterCommit pour les jobs qui dépendent de données fraîchement créées ou modifiées dans une transaction, par exemple un job d'envoi d'email après création de commande.
3Qu'est-ce que l'idempotence dans le contexte des systèmes distribués Laravel ?
Qu'est-ce que l'idempotence dans le contexte des systèmes distribués Laravel ?
Réponse
L'idempotence signifie qu'une opération peut être exécutée plusieurs fois sans changer le résultat au-delà de la première exécution. Dans Laravel, cela empêche les effets indésirables lors de retries de jobs ou de messages dupliqués. Par exemple, un job de création de commande idempotent vérifie si la commande existe déjà avant de la créer, évitant les doublons si le job est retraité suite à un timeout. Utiliser ShouldBeUnique, WithoutOverlapping ou deduplicationId pour garantir l'idempotence.
Quel est l'avantage principal d'utiliser les events plutôt que le dispatch direct de jobs pour la communication entre services ?
Dans quel contexte utiliser ShouldBeEncrypted pour les queued jobs ?
+19 questions d'entretien
Autres sujets d'entretien Laravel
Les bases de PHP
POO en PHP
Composer & Autoloading
Fondamentaux Laravel
Routing Laravel
Blade Templates
Request & Response
Eloquent ORM - Les bases
Eloquent Relationships
Migrations & Schema Builder
Validation & Formulaires
Authentication
Authorization & Policies
API Resources & Authentication
Middleware
Service Container & DI
Queues & Jobs
Events & Listeners
Notifications & Mail
File Storage
Testing & PHPUnit
Caching
Livewire & Inertia
Eloquent Advanced
Repository Pattern
Laravel Packages
Performance Optimization
Security Best Practices
Laravel Octane
Observability & Monitoring
Deployment & DevOps
Maîtrise Laravel pour ton prochain entretien
Accède à toutes les questions, flashcards, tests techniques, exercices de code review et simulateurs d'entretien.
Commencer gratuitement