10.02.2026
«Просто добавьте кеш» — одна из самых частых рекомендаций, которую дают, когда сервис
начинает тормозить. Проблема в том, что кеш — это не переключатель «быстро/медленно», а
отдельная область со своими собственными способами всё сломать. Разберём по порядку.
Зачем вообще нужен кеш
Кеш имеет смысл, когда вычисление или получение данных дороже, чем их повторное
использование. Классический пример — результат тяжёлого запроса к базе, который не
меняется каждую секунду: список категорий товаров, агрегированная статистика за день,
результат вызова внешнего API с лимитом запросов.
25.06.2025
За годы работы с PostgreSQL у меня накопился короткий список привычек, которые кажутся
мелочью, пока не спасут вас от инцидента в два часа ночи. Делюсь пятью, которые считаю
обязательными для любого проекта, где база — не игрушка.
1. Индекс на внешний ключ — не автоматический
В отличие от некоторых других СУБД, PostgreSQL не создаёт индекс на колонку внешнего ключа
автоматически. Если у вас таблица orders с user_id, ссылающимся на users, и вы не
добавили индекс вручную — удаление пользователя с большим числом заказов может
заблокировать таблицу на неприятно долгое время. Я завёл себе правило: индекс на FK
добавляется в той же миграции, что и сам внешний ключ, без исключений.
18.03.2025
Есть два типа логов: те, что пишутся для человека, который читает их глазами прямо сейчас,
и те, что пишутся для системы, которая будет их искать, фильтровать и агрегировать. Долгое
время я писал логи первого типа, и это работало ровно до тех пор, пока сервисов стало
больше одного.
Как выглядела проблема
Классическая строка лога вида log.Printf("user %s created order %d", userID, orderID)
прекрасно читается в консоли во время разработки. Но когда нужно найти все ошибки по
конкретному пользователю за последний час среди миллионов строк в централизованном
хранилище логов, текстовый поиск по подстроке — это очень медленный и ненадёжный способ.
20.02.2025
Полтора года назад я начал пет-проект — небольшой сервис для учёта личных расходов — и на
радостях сразу нарисовал схему из семи микросервисов: авторизация, транзакции,
категории, отчёты, уведомления, импорт банковских выписок и API-шлюз. Через месяц я всё
это снёс и написал заново в виде одного монолитного приложения. Хочу объяснить, почему.
Соблазн красивой архитектуры
На работе я много имею дело с распределёнными системами, и мне казалось естественным
переносить этот опыт на личный проект. Микросервисы выглядят солидно на диаграмме, каждый
сервис — отдельная ответственность, всё по книжке. Проблема в том, что книжка писалась для
команд из десятков человек и систем с реальной нагрузкой, а не для одного разработчика,
который открывает ноутбук по вечерам два раза в неделю.
14.11.2024
Три года назад я относился к очередям сообщений с суеверным страхом. Казалось, что стоит
только добавить в систему брокер — и вместо одной проблемы получаешь три: недоставленные
сообщения, дублирование и загадочные зависания консьюмеров по пятницам вечером. Сейчас я
понимаю, что боялся не самих очередей, а того, что не читал документацию дальше раздела
«быстрый старт».
С чего всё началось
Первый проект с очередью я унаследовал от коллеги, который уволился за неделю до релиза.
RabbitMQ был настроен так, что при падении одного консьюмера сообщения копились в памяти
брокера, пока диск не заканчивался. Это работало, пока нагрузка была маленькой, и
превратилось в еженедельный ритуал перезапуска, когда нагрузка выросла.