Сьогодні Redis — це де-факто стандарт для кешування у сервісах застосунків. Він неймовірно швидкий і простий у використанні, що дало йому значну перевагу на ринку. Однак із зростанням складності системи Redis має кілька обмежень, які впливають на надійність і доступність вашої системи, особливо під високим навантаженням. У 2025 році ми починаємо поступово відмовлятися від Redis і переосмислювати підхід до кешування загалом. У цій доповіді я поділюся своїм баченням проблеми та її вирішення. Ми розглянемо виклики, пов’язані з Redis, та альтернативні рішення для створення більш стійких і масштабованих систем.

<p>На цій доповіді ознайомимося з TechEmpower Web Framework Benchmarks, розглянемо узагальнені (не залежні від мови програмування) підходи до оптимізації Веб додатку та його оточення для досягнення екстремальних навантажень, і головне - як деякі речі можна застосувати на практиці в Ваших проєктах. </p>

<p>Прямі втрати від даунтайму в 1 хвилину = $5-$10 тисяч доларів. Репутація – безцінна. </p> <p>У рамках доповіди розглянемо архітектурні стратегії, що необхідні для розробки високонавантажених фінтех-рішень. Зосередимось на використанні черг і стрімінгу для ефективної роботи та керування великими обсягами даних у реальному часі та заради мінімізації затримок. </p> <p>Особливу увагу зосередимо на архітектурних патернах, використаних при проєктуванні фінтех-системи, мікросервісах і event-driven архітектурі, що забезпечують масштабованість, відмовостійкість та узгодженість усієї системи. </p>

<p>Чи Node.js підходить для високонавантажених додатків? Так! Але що робить звичайний Node.js додаток підходящим до високого навантаження, який витримає навантаження 100тис/c за адекватну ціну? В моїй розповіді ми пройдемо через потенційні вузькі місця в додатку, як їх знайти і як з ними боротися. Які метрики нам можуть показати потенційні проблеми? Як визначити, коли і як масштабувати наш додаток? Також, я розкажу про цікаві випадки пошуку проблем в реальних високонавантажених Node.js додатках. </p>