Як прискорити API у 5 разів змінивши формат даних (і чому це спірне рішення)

Один з API-ендпоінтів, який віддавав історію транзакцій обсягом 15 000+ записів, працював вкрай повільно — середній час відповіді становив 847 мс. Спроби оптимізувати базу даних майже не дали результату: SQL-запит виконувався приблизно за 94 мс, тобто вузьке місце було не в БД.

У чому була проблема

Профайлінг показав несподіваний результат: близько 722 мс витрачалося на серіалізацію даних у JSON і передачу payload мережею.

Прийняте рішення

Замість JSON було використано MessagePack — бінарний формат серіалізації, який підтримує ті самі структури даних, але зберігає їх у компактнішому та ефективнішому вигляді.

Результати (15 000 записів)

• ⏱ Час відповіді: 847 мс → 159 мс (прискорення у 5.3×)
• 📦 Розмір payload: 4.2 MB → 1.1 MB (—74%)
• 🧠 Парсинг на клієнті: 194 мс → 41 мс

Уся зміна обійшлася приблизно в 47 рядків коду — правки на бекенді (Python) і фронтенді (JavaScript).

Обмеження та нюанси

• Відповіді у MessagePack нечитабельні для людини — у браузері це виглядає як бінарні дані, а не JSON
• Для маленьких відповідей виграш мінімальний або відсутній

Але найцікавіше було у коментарях

Автор зазначив, що пагінація не використовувалася, оскільки її заборонив продакт. У відповідь коментатори справедливо зауважили: проблема була не в JSON як такому.

JSON є де-факто стандартом для API і чудово працює у звичайних request—response сценаріях. Але в цьому випадку ендпоінт фактично перетворився на bulk-експорт даних. Перехід на MessagePack просто зменшив payload і приховав архітектурну проблему.

Висновок

Система могла залишитися на JSON, якби дизайн був іншим:

• пагінація
• стрімінг (chunked responses)

🌎 Оригінал: medium.com

Якщо вам цікаво читати шортси англомовних статей українською, то ви можете більше для себе знайти у моєму блозі crynet.dev

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті