Natomiast pehap jest tragiczny jezeli owo api ma cokolwiek przetwarzac, zupelny brak asynchronicznosci na jakimkolwiek poziomie.
Przetwarzać w jakim sensie? Podasz jakiś przykład? ;)
Wszelkie operacje, które powodują zapisy, przykładowo obsługa zamówień w dużym systemie, gdzie jest integracja z systemami księgowymi, płatnościami, mailingiem, supportem. Takie coś nie robi sie w czasie zycia requestu, tylko odklada na kolejke i przetwarza asynchronicznie ze wzgledu na opoznienia i kilka puntkow integracji / awarii. Samo 'api' jest wtedy jedynie routerem ktory odklada zadania do kolejki, a z tylu backend przetwarza je i skaluje sie go wzgledem architektury persisetnce. Np: uzywasz MySQL czy RDS na amazonie i wydajnosc tego jest dość niska, a moze byc znacznie wiecej transakcji w czasie niz przepustowosc.
Da sie to zrobic w pehapie, np: z rabbitmq albo gearmanem, ale jest to i tak klepanie kodu od zera. Dodatkowo masz wtedy procesy pehapa ktore dzialaja w tle i samo zarzadzanie nimi to dramat, zarzadzanie pamiecia kuleje, wykrywanie problemow jak rozlaczanie uslug, restarty itd - problem, brak poolingu - problem. W celery i bardziej zaawansowanych technologiach, takie rzeczy masz wbudowane we "framework" wiec skupiasz sie na problemie, a nie na budowaniu samego systemu kolejki.