Как ответить
Когда мы мигрировали монолит на микросервисы, дедлайн горел — через месяц нужно было запустить новую платёжную систему. До этого я только читал про Kafka, но не работал с ней. Задача была простая: организовать надёжную доставку событий между сервисами, а времени на полноценное обучение не было.
Я действовал так: научиться базе за день, затем — сразу прототип под критический путь, а после — детали по мере необходимости. Конкретно:
- День 1: прочитал официальную документацию Kafka (Quickstart, ключевые концепции: partition, consumer group, offset). Бегло — не пытался выучить всё, только то, что нужно для гарантированной доставки. Посмотрел одно видео на YouTube (Google TechTalks) про паттерны обработки ошибок в Kafka.
- Дни 2-3: написал POC — простой producer и consumer с отказоустойчивостью: reconnection, retry с exponential backoff, dead letter queue. Код был неидеальный, но работающий. Главное — проверил на тестовом стенде, что сообщения не теряются при падении брокера.
- Дальше: когда запускали в прод, всплыли нюансы с мониторингом — добавил метрики (lag, errors). На каждую проблему — не гуглил абстрактно «как улучшить Kafka», а искал конкретные решения под свою задачу.
Весь ramp-up занял примерно 3 дня до рабочего прототипа. В итоге платёжка запустилась вовремя, потеряли несколько сообщений из-за неправильного commit offset’а на втором дне, но быстро поправили. Из уроков: не бояться писать сырой код и сразу тестировать на реальных данных, а не в изоляции.
Этот подход я теперь использую для любых новых инструментов под давлением: быстрое погружение в 20% нужной теории → прототип → итеративное улучшение. Без параллельного изучения всего подряд.