Веб Мастерская | Веб разработка и программирование | ИТ | IT
Без категории · 26 сентября 2026 г.
КЕЙС:
КЕЙС: Как мы сократили время ответа API с 3 секунд до 200 миллисекунд Коллеги, расскажу историю, от которой у меня до сих пор глаз дёргается. Приходит клиент: «Сергей, у нас интернет-магазин, пользователи жалуются — сайт тормозит». Открываю консоль, делаю запрос к каталогу товаров... 3,2 секунды. ТРИ. СЕКУНДЫ. На простую выдачу карточек. Разбираю, что там внутри. А там целый букет: ❌ 47 запросов к базе на одну страницу. Каждый товар подтягивал отзывы отдельным запросом. Нет, не шучу. Цикл на 47 итераций, внутри каждой — SELECT. ❌ Никакого кэширования. Один и тот же список категорий пересобирался на каждый запрос заново. ❌ Тяжёлая сериализация. Из базы выгребались ВСЕ поля, включая историю изменений, логи, черновики. А на фронт летело 5 из них. Что сделали за 3 дня: ✅ Переписали на JOIN + EAGER LOAD. 47 запросов → 3 запроса. Банально, но работает безотказно. ✅ Подключили Redis для каталога и категорий. TTL — 5 минут. Инвалидация по событию обновления товара. ✅ Вынесли тяжёлые поля из основного ответа. Сделали отдельный эндпоинт для детальной карточки. Список отдаёт только то, что реально рендерится. ✅ Добавили индекс на составной ключ (categoryid, status, createdat). EXPLAIN перестал показывать full table scan. Результат 3200 мс → 190 мс. Нагрузочное тестирование через k6: 200 RPS держит без деградации. Что важно: мы не переписывали бэкенд, не меняли язык, не ставили микросервисы. Просто убрали мусор и включили голову. Мораль для джунов и не только: прежде чем лезть в архитектурные решения — откройте лог запросов. В 80% случаев проблема не в технологиях, а в том, КАК они используются. Если у вас похожая боль — пишите в личку, разберём. А если просто хотите видеть такие разборы чаще — ставьте 🔥. Вот так. Идем кодить дальше! 🚀 #вебразработка #оптимизация #API #бэкенд #базаданных #Redis #кэширование #производительность #SQL #junior #фриланс #вебмастерская #продакшен #кейс #разработкасайтов