Ошибки в работе программы, баги, не только вызывают негативную реакцию у пользователей программы, и, соответственно, у заказчика, но ещё тормозят процесс разработки и поставки новых фич, т.к. нужно тратить время и ресурсы на их исправление, тестирование и поставку. И хотя фикс небольшого бага, может занимать совсем немного времени, но когда таких небольших багов становится много и они идут нескончаемым потоком, то такая разработка начинает напоминать корабль, в котором матросы постоянно латают дыры в корпусе, возникающие снова и снова. Откуда появляются эти пробоины и как сделать так, чтобы корпус корабля был более крепким и устойчивым к ним? Об этом я расскажу в своём докладе, где поделюсь своими идеями и опытом разработки программ устойчивых к багам.

Можно ли со стопроцентной уверенностью сказать, что эра монолитов закончилась? Не думаю, пик хайпа и популярности микросервисов все еще очень высок, иногда это превращается даже в карго культ. Индустрия сейчас испытывает слепую веру в микросервисы. Мы все еще видим и читаем по нескольку раз в неделю посты в популярных блогах о том, что кто-то "распилил" свой монолит на 100500 микросервисов, однако есть и исключения из правил. Мы даже наблюдали несколько громких случаев миграций от микросервисов обратно к монолиту (например, некоторые сервисы Amazon, такие как Prime Video). При переходе от одного большого приложения к нескольким сервисам меньшего размера вам придется решать множество новых проблем — о них я и хотел поговорить в своём докладе. Какие "оверхеды" с точки зрения производительности и трудозатрат приносит микросервисная архитектура? Стоит ли делать однозначный выбор в пользу микросервисной архитектуры на новых проектах?

Есть стандартная задача: сохранять изменения в БД и отправлять об этом сообщение в Кафку. Причём хочется, чтобы было честно: успешно отправили и успешно сохранили, либо же — ничего не отправили и ничего не сохранили.
Во всех учебниках предлагают использовать паттерн Transactional Outbox. Но так ли он хорош? Есть ли альтернативы? И что лучше? Обо всём этом поговорим на митапе.