реFUCKторинг

Работаю сейчас в довольно крупной компании на позиции ведущего разработчика с ролью TL. Занимаюсь разработкой сервиса, который в обозримом будущем станет принимать приличную нагрузку. И по договоренностям с клиентами время ответа (HTTP) нашего сервиса должно быть не более 65мс. Когда я пришел в компанию в июне 2022 года, время ответа уже составляло примерно 50мс при нагрузке в пике около 80 RPS. Стек на тот момент: Java 11 (Spring MVC) + PostgreSQL + Apache Ignite в качестве кэша. Проблема is coming Чуть больше года назад время ответа внезапно начало расти при той же нагрузке, но т.к. запас еще был, то никто особо не придавал этому значения...

Года полтора назад работал над одним проектом. Развернут он был на AWS. Сервис на Java работал с БД DynamoDB (NoSQL). В какой-то момент в логах посыпались ошибки, что приложение не может сохранить данные в БД из-за дублирования ключа. Я был удивлен, поскольку в коде для работы с данными использовал HashSet, и был уверен, что дубликаты не могут существовать. Оказалось - еще как могут. Если при работе, например, со строками HashSet хранит данные как положено, то при работе с объектами ситуация совсем другая. Мы вполне законно можем закинуть объект в HashSet и после этого дальше использовать и модифицировать его в коде...