Operațiile lente — trimitere email, generare PDF, apeluri API — nu ar trebui să țină utilizatorul pe un spinner HTTP până expiră timeout-ul proxy-ului. Cozile mută munca în background și permit retry controlat. Discuția clarifică cum funcționează dispatch-ul, ce se întâmplă când workerul lipsește pe hosting partajat și cum tratezi eșecurile fără a pierde evenimente critice.
Cu `QUEUE_CONNECTION=sync`, job-ul rulează imediat în request — util local, periculos dacă uiți să schimbi în producție. Driver database e ușor de pornit fără Redis, dar devine bottleneck la volum. Redis sau SQS adaugă infrastructură dar scalează mai bine. Verifică în `.env` pe server valoarea reală; multe incidente „emailul nu pleacă” sunt de fapt job-uri care stau în tabelul `jobs` fără consumator.
Reîncercările pot duplica email-uri dacă job-ul nu e idempotent — folosește `ShouldBeUnique` sau verificări de stare înainte de trimitere. Timeout și `tries` configurează cât persistă efortul. Serializarea modelelor în job păstrează id-ul; la retry, reîncarcă modelul fresh din DB. Evită payload-uri uriașe în job; stochează referințe și reconstruiește datele la procesare ca să nu umpli tabelul de cozi.
Tabelul `failed_jobs` stochează payload și excepție; `queue:retry` reia manual după fix. Loghează context business (user id, tip notificare) în job, nu doar stack trace. Pe hosting fără daemon, cron cu `--stop-when-empty` procesează batch-uri mici. Alertarea când `failed_jobs` crește previne acumularea tăcută a mesajelor nederivate, mai ales după schimbări SMTP.
Notificările pot folosi mail, database, broadcast; alege canalul în clasa notificare. Implementează `ShouldQueue` pe notificare sau mail ca să nu blochezi răspunsul. Testele cu Queue::fake() verifică dispatch fără execuție reală. Pentru email de verificare cont, coada separă latenta SMTP de timpul de răspuns al formularului de înregistrare — utilizatorul primește feedback imediat, mesajul pleacă când workerul e disponibil.
Driver sync versus database/redis
Cu `QUEUE_CONNECTION=sync`, job-ul rulează imediat în request — util local, periculos dacă uiți să schimbi în producție. Driver database e ușor de pornit fără Redis, dar devine bottleneck la volum. Redis sau SQS adaugă infrastructură dar scalează mai bine. Verifică în `.env` pe server valoarea reală; multe incidente „emailul nu pleacă” sunt de fapt job-uri care stau în tabelul `jobs` fără consumator.
Job design idempotent
Reîncercările pot duplica email-uri dacă job-ul nu e idempotent — folosește `ShouldBeUnique` sau verificări de stare înainte de trimitere. Timeout și `tries` configurează cât persistă efortul. Serializarea modelelor în job păstrează id-ul; la retry, reîncarcă modelul fresh din DB. Evită payload-uri uriașe în job; stochează referințe și reconstruiește datele la procesare ca să nu umpli tabelul de cozi.
Failed jobs și monitorizare
Tabelul `failed_jobs` stochează payload și excepție; `queue:retry` reia manual după fix. Loghează context business (user id, tip notificare) în job, nu doar stack trace. Pe hosting fără daemon, cron cu `--stop-when-empty` procesează batch-uri mici. Alertarea când `failed_jobs` crește previne acumularea tăcută a mesajelor nederivate, mai ales după schimbări SMTP.
Notificări versus Mailable
Notificările pot folosi mail, database, broadcast; alege canalul în clasa notificare. Implementează `ShouldQueue` pe notificare sau mail ca să nu blochezi răspunsul. Testele cu Queue::fake() verifică dispatch fără execuție reală. Pentru email de verificare cont, coada separă latenta SMTP de timpul de răspuns al formularului de înregistrare — utilizatorul primește feedback imediat, mesajul pleacă când workerul e disponibil.