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