Цікаво чи може бути, що це пов’язано з відходом від NGINX на Pingora?

Був в мене опит з асинхронністю на FastAPI.
Потрібно було зробити апкку, яка має 3 арі по вебсокетах для 3х сутностей
1) клієнт(SSR Next.js)
2) сапорт(SPA React)
3) виконавець(SPA React)),
Так же для кожної сутноті має бути http арі, яке відправляє івенти по певній логіці на 3 сутності.
Відповідно арі по вебсокетах це типу шлюз доставки повідомлень різних типів івентів(тобто відкрили сторінку, проінітилось з’єднання по вебсокетах і повідомлення які приходять взалежності від івент ід делегуються хендлеру який процесить такий івент)

Коротенький R&D показав що задачка реалізуєма і по класиці: локально все працює!

Так як в на python маємо GIL то бек uvicorn+gunicorn+nginx і отримуємо n-воркерів (копій FastAPI аплікух) і між ними потрібно синхронізація для вебсокетів бо вебсокет з’єднання одного користувача може бути на різних процесах, для цього використав aioredis з Pub/Sub. Але спочатку це все жило на кубернетусі і поки жило то вроді як все ок)))

Нагрузки на таку апку постійні і одночасно десь до 30 користувачів але через пару днів стукає девопс і каже що в нього чогось поди відвалються, і показує метрики: пода за 26 годин виїдає 1.5гб оперативки і крашиться. Рішення просте 1гб виїло кілаєм поду і стартуєм нову і по вебсокетам івент пінг/понг кожні 30сек, якщо на пінг не прийшов понг то фронти роблять реконект — костилі крутяться, а деви з девопсами мутяться!

Пройшло десь рік і рішили трохи на інфрі затягнути пояси, прийшлось підіймати це на IaaS (Hetzner): локально та на стейджі все ок, а от в проді постійно відвалювася редіс зі своїм Pub/Sub та ще й з такими помилками що особо не гуглиться, поковирявся я з цим і на вихідних з chat gpt переписав апку на golang(зовнішній сторедж в цьому варіанті не потрібен бо вебсокет зєднання кладуться в глобальні змінні і за допомогою RWMutex в горутінах достаються конкретні зєднання яким потрібно відправити івент)+nginx і все працює стабільно і без проблем.

Посил коментаря: в мові Python можна підчас R&D знайти солюшен і зробити реалізацію але чи буде вона оптимальною і ефективною то це виливається в розуміння ОБМЕЖЕНЬ реалізації самої мови та її механізмів! Тому, маючи GIL і відсутність фонових задач яку приходиться вирішувати через брокери з celery або аналогами, варто розуміти що реалізація асинхронності в Python як було сказано в статті не конфліктує з GIL і мабуть можна сказати що неповноцінна бо хоть і є стандарти але ті ж бібліотекти обгортаються синхроний IO, а так же із за того що асинронність є механізмом кооперації то хто як хоче так і лячкає і в результаті баланс при якому корутіни мають збільшити нагрузку яку може один процес хендлити ми отримуємо деградацію. Виходить що при асинхроності потрібно думати про баланс, слідкувати за тим щоб корутіни були короткі по виконанню і тоді буде виграш.

SQLAlchemy 2x була релізнута в 23 році, а ви в 25році використовуєте 1.х версію в статті, печалька(((

На вході вимоги, а на виході рішення на основі бюджету і людей. З цього випливає що рішення може бути з гімна і палок на будь-якій БД!
Тому коли ви пишете про 5ть 9ток, то навіть на AWS зробити рішення на 99,999 дуже сумнівно, в 99,99 ше повірю, а тут ви позиціонуєте що взявши Oracle ви тут же отримаєте 99,999. Не від однієї БД залежить SLA)))
У вас може бути MySQL з декількома користувачами і давати при вдалих обставинах за 10 років 99,9999

На мою думку в порівнянні реляційних БД один із важливіших критеріїв — це транзакційність. Було б дуже добре, якщо в темі роботи транзакцій ще й розглянути Race Condition в порівняні цих БД. Тема транзакцій серйозна і в той же час гаряча та палка)))

А запис доповідей буде?