Een taakqueue ontwerpen voor trage bewerkingen in PHP

Een bewerking die meerdere seconden duurt, kan een HTTP-verzoek open laten staan, resources van de webserver verbruiken en de gebruiker een onzekere ervaring bieden als de verbinding wordt onderbroken. PHP-processen op de achtergrond maken het mogelijk om werk aan te nemen en uit te voeren buiten de levenscyclus van dat verzoek. Om de oplossing bruikbaar te maken, volstaat het niet om een queue toe te voegen: je moet bepalen wat de gebruiker te zien krijgt, hoe die de status opvraagt en wat er gebeurt bij een onderbreking.

Bepalen welke bewerkingen op de achtergrond moeten worden uitgevoerd

Het is verstandig om de impact van een bewerking te beoordelen en niet alleen een regel op basis van de duur toe te passen. Een taak kan hiervoor in aanmerking komen als de uitvoeringstijd variabel is, als er op een extern systeem moet worden gewacht of als er veel items worden verwerkt. Voorbeelden zijn het genereren van een uitgebreid rapport, het importeren van een bestand, het transformeren van documenten of het synchroniseren van gegevens met een API.

Als de gebruiker daarentegen onmiddellijk een beslissing nodig heeft om verder te kunnen — bijvoorbeeld om essentiële gegevens te valideren voordat ze worden opgeslagen — kan het beter zijn dat deel binnen het verzoek uit te voeren en alleen het vervolgwerk af te splitsen. Ook zijn er trage taken waarvoor vanwege zakelijke vereisten een synchrone reactie nodig is. De architectuur moet aansluiten op de behoeften van de workflow; maak niet elke bewerking asynchroon.

Breng vóór het aanpassen van het ontwerp in kaart hoe lang de bewerking duurt, welk onderdeel die tijd in beslag neemt en wat er gebeurt als de bewerking mislukt. Een queue lost inefficiënte queries, verkeerd geconfigureerde limieten of instabiele externe afhankelijkheden niet vanzelf op; die problemen kunnen hierdoor juist worden verplaatst naar de achtergrondworkers.

Antwoord dat een taak is aangenomen, niet met een verzonnen resultaat

Wanneer werk wordt aangenomen voor latere uitvoering, moet het antwoord van de applicatie duidelijk onderscheid maken tussen aangenomen en voltooid. Het kan een taak-ID teruggeven en aangeven dat de verwerking nog in behandeling is. Presenteer een resultaat dat nog niet bestaat niet als voltooid.

Een schatting van de duur is alleen geschikt als er voldoende informatie is om die te berekenen en de onzekerheid ervan te communiceren. In veel systemen is het eerlijker om een status als ‘in de wachtrij’ of ‘wordt verwerkt’ weer te geven dan een tijdstip van voltooiing te beloven. Als de taak snel kan worden afgerond, kan de interface de status nog steeds opvragen en het resultaat tonen zodra het beschikbaar is, zonder het oorspronkelijke verzoek te blokkeren.

Bepaal ook wat er gebeurt als het versturen naar de queue mislukt: de applicatie mag de taak niet als aangenomen bevestigen als die het werk niet betrouwbaar kan registreren. Het concrete mechanisme hangt af van de architectuur, maar het antwoord en de opgeslagen status moeten met elkaar overeenkomen.

Geldige statussen en overgangen definiëren

Een kleine, expliciete levenscyclus maakt de gebruikerservaring en de werking eenvoudiger. Als basis kun je de statussen in_wachtrij, bezig, annulering_aangevraagd, voltooid, mislukt en geannuleerd gebruiken. De namen kunnen verschillen; de overgangen moeten daarentegen geldig en controleerbaar zijn, geen willekeurige combinatie van statussen.

• Normale overgangen: in_wachtrij → bezig en vanuit bezig naar voltooid of mislukt.
• Annulering voordat de taak begint: in_wachtrij → geannuleerd als is bevestigd dat de worker nog niet met het werk is begonnen.
• Annulering tijdens de uitvoering: bezig → annulering_aangevraagd. Vanuit die status gaat de taak naar geannuleerd als deze veilig wordt gestopt; de status kan voltooid worden als de taak is afgerond voordat het verzoek is verwerkt, of mislukt als er een fout is opgetreden.
• Eindstatussen: voltooid, mislukt en geannuleerd mogen niet teruggaan naar actieve statussen. Als een taak opnieuw mag worden uitgevoerd, maak dan een nieuwe uitvoering aan of definieer uitdrukkelijk een andere levenscyclus.

Het systeem moet niet-toegestane overgangen verhinderen en registreren wanneer elke wijziging plaatsvond. Als een worker wordt onderbroken en een taak de status bezig houdt, markeer die dan niet automatisch als voltooid. Een herstelbeleid kan de taak terugzetten naar in_wachtrij wanneer hervatten veilig is, of deze markeren als mislukt voor controle. De keuze hangt ervan af of het werk kan worden hervat zonder effecten te dupliceren. De coördinatie van retries en idempotentie vereist eigen beslissingen; verwar die niet met het zichtbare statusmodel.

Voortgang, resultaat en fouten communiceren

De voortgang moet zijn gebaseerd op meetbare mijlpalen. Als een werkelijk percentage niet kan worden berekend, kun je beter de fase melden (‘gegevens valideren’, ‘rapport genereren’) of de status ‘bezig’ aanhouden. Een percentage dat stilstaat of zonder uitleg terugloopt, vermindert het vertrouwen.

Bied na voltooiing het zakelijke resultaat aan: bijvoorbeeld een overzicht van verwerkte items of een verwijzing naar de gegenereerde resource, afhankelijk van de toegangsrechten en beschikbaarheid. De taakstatus hoeft niet het volledige resultaat op te slaan. Er kan een verwijzing worden opgeslagen naar gegevens die door het domein van de applicatie worden beheerd.

Toon bij een fout een bericht dat helpt bij het bepalen van de volgende stap, zoals het corrigeren van een bestand of het opnieuw proberen wanneer dat passend is. Registreer afzonderlijk de technische fout die nodig is voor diagnose, met beperkte toegang. Stel geen stacktraces, inloggegevens, interne paden of gevoelige gegevens beschikbaar in de interface of een publieke API.

Annulering behandelen als een verzoek met beperkingen

Een taak annuleren betekent niet altijd dat die onmiddellijk kan worden gestopt. Een worker kan een externe aanroep uitvoeren, gegevens wegschrijven of zich in een fase bevinden die niet veilig kan worden onderbroken. Daarom moet de interface onderscheid maken tussen annulering_aangevraagd en geannuleerd: de eerste status geeft aan dat het verzoek is ontvangen; de tweede dat het systeem heeft bevestigd dat de taak is gestopt.

De implementatie kan op veilige momenten controleren of er een annuleringssignaal is en geen volgende stappen meer starten. Als het effect al in een extern systeem is bevestigd, mag niet worden beweerd dat dit ongedaan is gemaakt. Leg de gebruiker uit welk resultaat die kan verwachten en registreer wie de annulering heeft aangevraagd wanneer dat relevant is voor audits.

De taakregistratie scheiden van het zakelijke resultaat

De registratie van een taak dient om de uitvoering en raadpleging ervan te coördineren: deze kan een ID, status, tijdstippen, aanvrager en verwijzingen voor diagnose bevatten. Het zakelijke resultaat — bijvoorbeeld een rapport of de geïmporteerde records — hoort bij het gegevensmodel dat dat resultaat vertegenwoordigt.

Door deze zaken te scheiden, voorkom je dat een taak met tijdelijke informatie de enige bron voor het zakelijke resultaat wordt. Zo kun je ook bewaartermijnen vastleggen: hoelang de status wordt bewaard, wanneer een bestand wordt verwijderd en welke informatie vanwege operationele of wettelijke verplichtingen moet blijven bestaan. Oude statussen mogen zich niet zonder opschoningsbeleid opstapelen.

Raadpleging beveiligen en resourceverbruik beperken

Voor het raadplegen van een taak is autorisatie nodig, net als voor het raadplegen van elke andere resource. Een ID vervangt de toegangscontrole niet: controleer of de aanvragende persoon of het systeem die taak en het resultaat ervan mag zien. Beperk ook de frequentie en het aantal raadplegingen om overmatig pollen te voorkomen, en overweeg notificaties wanneer de use case geen doorlopende updates vereist.

De uitvoering moet grenzen hebben voor concurrency en resources die passen bij het type werk. Te veel workers kunnen de database, externe services of opslag overbelasten; te weinig workers kunnen taken laten ophopen en resultaten vertragen. Houd naast fouten ook het aantal taken in de wachtrij, de ouderdom van taken en de uitvoeringstijden in de gaten. Deze signalen helpen onderscheid te maken tussen een trage afhankelijkheid en een capaciteitsprobleem.

De volledige levenscyclus testen voordat je uitrolt

Acceptatietests moeten het zichtbare gedrag en de persistente opslag controleren, niet alleen of de worker een functie aanroept. Test ten minste de volgende scenario’s:

• Het verzoek maakt een taak aan en geeft een verwijzing terug zonder te beweren dat de taak al is voltooid.
• Bij een voltooide taak wordt de eindstatus weergegeven en is het resultaat toegankelijk met de juiste toegangsrechten.
• Bij een mislukte taak wordt een veilig bericht getoond en blijft diagnose-informatie toegankelijk voor het bevoegde team.
• Een verlaten of onderbroken taak blijft niet voor onbepaalde tijd ‘bezig’; er is een operationele manier om die te detecteren en af te handelen.
• Een annuleringsverzoek houdt rekening met veilige fasen en belooft niet dat reeds uitgevoerde effecten ongedaan worden gemaakt.

Voer de wijziging in een bestaand systeem eerst in voor één afgebakende bewerking en controleer ook de ervaring wanneer de queue vertraging heeft of niet beschikbaar is. De applicatie moet in die gevallen duidelijk reageren: melden dat het werk niet kon worden aangenomen, een veilig alternatief bieden of de gebruiker de mogelijkheid geven het opnieuw te proberen. De keuze hangt af van de impact van de bewerking en van de garanties die het bedrijf kan waarmaken.

Checklist voor het introduceren van een queue in een bestaand systeem

Controleer deze punten samen met de teams die verantwoordelijk zijn voor de applicatie en de werking ervan voordat je achtergrondverwerking inschakelt:

• Scope: er is een concrete bewerking gekozen en bepaald welk deel synchroon blijft en welk werk op de achtergrond wordt uitgevoerd.
• Persistente opslag: de acceptatie van de taak en de status worden consistent opgeslagen; er is beleid voor onderbrekingen, herstel en statuswijzigingen.
• Afspraak met de gebruiker: het eerste antwoord maakt onderscheid tussen acceptatie en voltooiing, en de interface legt uit hoe de voortgang, het resultaat en fouten kunnen worden geraadpleegd.
• Toegangsrechten en gegevens: voor het raadplegen van een taak of het resultaat ervan is autorisatie vereist; opgeslagen gegevens worden geminimaliseerd en de toegang tot diagnose-informatie wordt beperkt.
• Resources: er zijn limieten vastgesteld voor concurrency, uitvoeringstijd, geheugen en de frequentie van raadpleging, afgestemd op de bewerking en de afhankelijkheden ervan.
• Observeerbaarheid: ophopingen, oude taken die nog bezig zijn, fouten en afwijkende uitvoeringstijden kunnen worden gedetecteerd zonder geheimen in logs op te nemen.
• Bewaartermijnen: er is bepaald hoelang statussen, resultaten, bestanden en diagnosegegevens worden bewaard en hoe deze gecontroleerd worden verwijderd.
• Tests en beheer: de scenario’s voor voltooiing, mislukking, annulering en onderbreking zijn getest, en het team weet wat het moet doen als de queue geen werk aanneemt of vertraging oploopt.

Code uitrollen is niet hetzelfde als alle workflows onmiddellijk inschakelen: je kunt de nieuwe uitvoeringsroute geleidelijk invoeren en de signalen controleren voordat je deze verder uitbreidt. Zorg voor een passende operationele terugvaloptie als de queue of de workers niet beschikbaar zijn; bevestig geen taken die het systeem niet heeft kunnen registreren.