Pour répondre à la première partie de votre question :Oui, vous pouvez faire des requêtes asynchrones avec PHP , et même ignorer la réponse du service. Cependant, comme vous le dites correctement, ce n'est pas une super solution.
Requêtes asynchrones
Cet excellent article de blog sur les requêtes asynchrones PHP par Segment.io arrive à plusieurs conclusions :
- Vous pouvez ouvrir un socket et y écrire , comme décrit par cette rubrique Stack Overflow - Cependant, il semble que cela soit en fait bloquant et assez lent (300 ms dans leurs tests).
- Vous pouvez écrire dans un fichier journal, puis le traiter d'une autre manière (essentiellement une file d'attente, comme vous le décrivez) - Cependant, cela nécessite un autre processus pour lire le journal et le traiter. L'utilisation du système de fichiers peut être lente et les fichiers partagés peuvent causer toutes sortes de problèmes.
- Vous pouvez forker une requête cURL - Cependant, cela signifie que vous n'attendez pas de réponse, donc si SendGrid (ou un autre service) répond avec une erreur, vous ne pouvez pas l'attraper et réagir.
Terre d'opinion 
Nous entrons maintenant dans le pays des semi-opinions , mais les files d'attente que vous décrivez (comme une file d'attente mySQL avec une tâche cron, ou un fichier texte, ou autre chose) ont tendance à être très évolutives car vous pouvez envoyer des travailleurs à la file d'attente si vous en avez besoin pour traiter plus rapidement. Ceux-ci peuvent se trouver en dehors de votre système en contact avec l'utilisateur (et donc ne pas partager de ressources).
Files d'attente
Avec une file d'attente, vous auriez un service distinct qui serait responsable de l'envoi d'un e-mail avec SendGrid (par exemple). Il retirerait des tâches d'une file d'attente (par exemple "envoyer un e-mail à Nick"), puis les exécuterait.
Il existe plusieurs façons d'implémenter des files d'attente que vous pouvez traiter.
- Vous pouvez écrire le vôtre - Comme vous semblez vouloir rester sur PHP/mySQL, si vous faites cela, vous devrez prendre en compte un tas de problèmes de file d'attente et des cas extrêmes étranges. Cependant, vous aurez un contrôle absolu et pour une application simple, cela fonctionnera peut-être.
- Vous pouvez implémenter une file d'attente de tâches auto-hébergée - Céleri est censé être une file d'attente de tâches distribuée, øMQ (ZeroMQ) et RabbitMQ peuvent également être utilisés comme files d'attente de tâches. Ceux-ci sont censés être rapides et distribués et ont fait l'objet de beaucoup de réflexion. Vous auriez besoin de les comparer dans votre système pour voir s'ils l'accélèrent. Cela signifierait également que vous devez héberger vous-même des pièces supplémentaires. Cependant, il s'agit probablement de la solution la plus rapide du point de vue de la communication.
- Vous pouvez transmettre des éléments à une file d'attente de tâches hébergée - IronMQ et Amazon SQS sont deux solutions hébergées intéressantes, ce qui signifie que vous n'auriez pas besoin de leur consacrer des ressources, en plus avec IronWorkers (par exemple) vous pourriez faire prendre en charge l'autre service. Cependant, puisque vous essayez d'optimiser une demande à un service externe, ce n'est probablement pas la solution dans ce scénario.
Mise en file d'attente des e-mails
En ce qui concerne la mise en file d'attente des e-mails (en particulier), c'est quelque chose de commun aux expéditeurs d'e-mails. Comme pour tout le reste, cela signifie que vous pouvez avoir une meilleure fiabilité (parce que si un service échoue, vous pouvez le garder dans la file d'attente et réessayer).
Cependant, avec le courrier électronique, il existe des services spécifiques pour la mise en file d'attente des messages. Ce sont des serveurs SMTP. Théoriquement, vous pouvez configurer un serveur comme sendmail puis définissez SendGrid comme votre "smarthost" ou relais et que le serveur envoie à SendGrid. Il met ensuite en file d'attente et traite les interruptions de service et envoie du courrier avec peu de code supplémentaire. Cependant , les serveurs SMTP sont pénibles à gérer, même s'ils ne font que transférer des messages. De plus, SMTP est encore plus lent que HTTP pour établir une connexion et donc probablement pas ce que vous voulez, mais c'est bon à savoir.
