For at besvare den første del af dit spørgsmål:Ja, du kan lave asynkrone anmodninger med PHP , og endda ignorere tjenestens svar. Men som du rigtigt siger, er det ikke en super god løsning.
Asynkrone anmodninger
Dette fremragende blogindlæg om PHP Asynkrone anmodninger af Segment.io kommer til flere konklusioner:
- Du kan åbne en socket og skrive til den , som beskrevet af dette Stack Overflow-emne - Det ser dog ud til, at dette faktisk er blokerende og ret langsomt (300 ms i deres test).
- Du kan skrive til en logfil og derefter behandle den på en anden måde (i det væsentlige en kø, som du beskriver) - Dette kræver dog en anden proces for at læse loggen og behandle den. Brugen af filsystemet kan være langsom, og delte filer kan forårsage alle mulige problemer.
- Du kan fordele en cURL-anmodning - Dette betyder dog, at du ikke venter på et svar, så hvis SendGrid (eller en anden tjeneste) svarer med en fejl, kan du ikke fange den og reagere.
Meningsland 
Vi er nu på vej ind i semi-opinionsland , men køer, som du beskriver (såsom en mySQL med et cron-job, eller en tekstfil eller noget andet) har en tendens til at være meget skalerbare, da du kan smide arbejdere i køen, hvis du har brug for, at den behandles hurtigere. Disse kan være uden for dit brugervendte system (og derfor ikke dele ressourcer).
Køer
Med en kø ville du have en separat tjeneste der ville være ansvarlig for at sende en e-mail med SendGrid (f.eks.). Det ville trække opgaver ud af en kø (f.eks. "send en e-mail til Nick") og derefter udføre på den.
Der er flere måder at implementere køer på, som du kan behandle.
- Du kan skrive din egen - Da du tilsyneladende ønsker at forblive på PHP/mySQL, hvis du gør dette, skal du tage højde for en masse køproblemer og mærkelige kantsager. Du har dog absolut kontrol, og for en simpel applikation vil dette måske virke.
- Du kan implementere en selv-hostet opgavekø - Selleri er beregnet til at være en distribueret opgavekø, øMQ (ZeroMQ) og RabbitMQ kan også bruges som opgavekøer. Disse er beregnet til at være hurtige og distribuerede, og der er lagt mange tanker i dem. Du bliver nødt til at benchmarke dem i dit system for at se, om de fremskynder det. Det ville også betyde, at du selv skal være vært for yderligere stykker. Dette vil dog sandsynligvis være den hurtigste løsning ud fra et kommunikationssynspunkt.
- Du kan videregive ting til en hostet opgavekø - IronMQ og Amazon SQS er begge fede hostede løsninger, hvilket betyder, at du ikke behøver at dedikere ressourcer til dem, desuden med IronWorkers (f.eks.) du kunne få den anden service varetaget. Men da du forsøger at optimere en anmodning til en ekstern tjeneste, er dette sandsynligvis ikke løsningen i dette scenarie.
Sæt e-mails i kø
Med hensyn til emnet e-mails i kø (specifikt) er dette noget, der er almindeligt for e-mail-afsendere. Ligesom med alt andet betyder det, at du kan få bedre pålidelighed (fordi hvis en tjeneste nede på linjen fejler, kan du beholde den i køen og prøve igen).
Med e-mail er der dog nogle specifikke tjenester derude til at sætte beskeder i kø. Disse er SMTP-servere. Teoretisk set kan du opsætte en server som sendmail og derefter indstil SendGrid som din "smarthost" eller relæ og få serveren til at sende til SendGrid. Derefter sætter den sig i kø og håndterer tjenesteafbrydelser og sender mail med lidt ekstra kode. Men , SMTP-servere er besværlige at håndtere, selvom de bare videresender beskeder. Derudover er SMTP endnu langsommere end HTTP til at etablere en forbindelse og derfor sandsynligvis ikke, hvad du ønsker, men det er godt at vide.