För att svara på den första delen av din fråga:Ja, du kan göra asynkrona förfrågningar med PHP , och till och med ignorera tjänstens svar. Men som du helt riktigt säger är det inte en superbra lösning.
Asynkrona förfrågningar
Detta utmärkta blogginlägg om PHP Asynchronous Requests av Segment.io kommer till flera slutsatser:
- Du kan öppna en socket och skriva till den , som beskrivs av det här Stack Overflow-ämnet - Det verkar dock som att detta faktiskt är blockerande och ganska långsamt (300 ms i deras tester).
- Du kan skriva till en loggfil och sedan bearbeta den på annat sätt (i huvudsak en kö, som du beskriver) - Detta kräver dock en annan process för att läsa loggen och bearbeta den. Att använda filsystemet kan vara långsamt och delade filer kan orsaka alla möjliga problem.
- Du kan fordra en cURL-begäran - Detta betyder dock att du inte väntar på ett svar, så om SendGrid (eller någon annan tjänst) svarar med ett fel, kan du inte fånga det och reagera.
Opinion Land 
Vi går nu in i semi-opinionsland , men köer som du beskriver (som en mySQL med ett cron-jobb, eller en textfil eller något annat) tenderar att vara väldigt skalbara eftersom du kan kasta arbetare i kön om du behöver det för att bearbeta snabbare. Dessa kan vara utanför ditt användarvänliga system (och därför inte dela resurser).
Köer
Med en kö skulle du ha en separat tjänst som skulle vara ansvarig för att skicka ett e-postmeddelande med SendGrid (t.ex.). Det skulle dra uppgifter från en kö (t.ex. "skicka ett e-postmeddelande till Nick") och sedan köra på det.
Det finns flera sätt att implementera köer som du kan bearbeta.
- Du kan skriva din egen - Eftersom du verkar vilja stanna på PHP/mySQL, om du gör detta måste du ta hänsyn till en massa köproblem och konstiga kantfall. Du har dock absolut kontroll och för en enkel applikation kanske detta fungerar.
- Du kan implementera en uppgiftskö med egen värd - Selleri är tänkt att vara en distribuerad uppgiftskö, øMQ (ZeroMQ) och RabbitMQ kan också användas som uppgiftsköer. Dessa är tänkta att vara snabba och distribuerade och har haft mycket eftertanke i dem. Du måste jämföra dem i ditt system för att se om de påskyndar det. Det skulle också innebära att du måste vara värd för ytterligare stycken själv. Detta är dock sannolikt den snabbaste lösningen ur kommunikationssynpunkt.
- Du kan skicka saker till en värduppgiftskö - IronMQ och Amazon SQS är båda coola värdbaserade lösningar vilket innebär att du inte behöver ägna resurser åt dem, dessutom med IronWorkers (t.ex.) du kan få den andra tjänsten omhändertagen. Men eftersom du försöker optimera en förfrågan till en extern tjänst, är detta förmodligen inte lösningen i det här scenariot.
Sätta e-post i kö
När det gäller att köa e-postmeddelanden (specifikt) är detta något vanligt för e-postavsändare. Precis som med allt annat betyder det att du kan få bättre tillförlitlighet (eftersom om en tjänst längre fram misslyckas kan du behålla den i kön och försöka igen).
Men med e-post finns det några specifika tjänster där ute för att köa meddelanden. Dessa är SMTP-servrar. Teoretiskt kan du ställa in en server som sendmail och sedan ställ in SendGrid som din "smarthost" eller relä och få servern att skicka till SendGrid. Den köar sedan och hanterar tjänstavbrott och skickar e-post med lite extra kod. Men , SMTP-servrar är svåra att hantera, även om de bara vidarebefordrar meddelanden. Dessutom är SMTP ännu långsammare än HTTP för att upprätta en anslutning och därför förmodligen inte vad du vill, men det är bra att veta.