👋 Добро пожаловать в Java && Management

Здесь — практические разборы Java/JVM, архитектуры, Kafka, эксплуатации и инженерного управления: первичные источники, актуальные релизы, диаграммы и выводы для решений.

Навигация:
• #Java — JVM, Spring и платформенные изменения
• #Kafka — очереди, события и идемпотентность
• #идемпотентность — retry, консистентность и надёжность
• комментарии — вопросы и разборы в связанном чате

Нужен независимый технический аудит Java/backend, инфраструктуры или интеграций?
→ https://krot.name/

Профили и кейсы: https://krot.name/profiles/

Решение важнее новостного пересказа

Информационного шума и так до хрена. Ценность технического контента не в том, сколько релизов я пересказал, а в том, помог ли разбор принять инженерное решение.

DORA сейчас использует 5 delivery metrics: 3 про throughput и 2 про instability. Сильные команды обычно хороши по всем пяти, но сама DORA предупреждает: чужие target без контекста — отличный способ красиво врать самим себе.

Google SRE показывает цену SLO за 30 дней:
— 99,9% оставляет 43 мин 12 с error budget;
— 99,99% — всего 4 мин 19 с.

Поэтому здесь схема простая: сигнал → доказательства → механизм → границы → решение. Иногда вывод будет скучным: пока ничего не менять. Это не трусость, а нормальная архитектура, если названы критерий и цена ожидания.

#Java #архитектура #исследования

Микросервисы: дорогой способ слишком рано почувствовать независимость

Микросервисы обещают независимые релизы, масштабирование и изоляцию отказов. А приносят сетевые вызовы, распределённое состояние и эксплуатационную координацию — сюрприз, бесплатной архитектуры не завезли.

Дэвид Парнас: модуль отделяют там, где он скрывает независимо меняющееся решение. Отдельный процесс нужен позже — когда независимость должна дойти до релиза, scaling или failure domain.

DeathStarBench 2019 собрал 6 end-to-end приложений: benchmark одного процесса не видит service graph и tail latency всей системы. В кейсе Prime Video workflow упёрся примерно в 5% ожидаемой нагрузки; после локальной консолидации команда сообщила о снижении инфраструктурной стоимости на 90%.

Это не «монолит всех победил». Архитектурная религия — херовый заменитель измерений. Стартовая позиция — модульный монолит; сервис выделяется при самостоятельной бизнес-границе и измеримом эксплуатационном давлении.

#Java #архитектура #микросервисы

@Transactional не накрывает сеть священным куполом

Транзакция сохраняет инвариант: изменение фиксируется целиком либо не фиксируется. Но её власть заканчивается на границе базы. HTTP и broker на аннотацию смотрят без благоговения.

По Spring Framework, @Transactional действует только в границе TransactionManager:
— self-invocation в proxy mode не перехватывается;
— checked exception по умолчанию не вызывает rollback;
— PostgreSQL принимает 4 названия isolation level, но реализует 3 режима: READ UNCOMMITTED работает как READ COMMITTED.

В READ COMMITTED каждый SELECT получает новый snapshot. SQLSTATE 40001 и deadlock 40P01 требуют повтора всей транзакции.

Для DB + broker данные и outbox фиксируются вместе. Debezium читает изменения через CDC, Event Router преобразует запись. Дубликаты возможны, consumer остаётся идемпотентным. Иначе получаем распределённый бардак с очень уверенной аннотацией.

#Java #Spring #транзакции

Exactly-once заканчивается там, где начинается бизнес

Идемпотентность нужна, чтобы retry не стал повторным платежом или заказом. Транспорт может сказать «ровно один раз», но внешней системе на его самооценку плевать.

В Apache Kafka 4.3 producer idempotence включена по умолчанию без конфликтующих настроек и требует acks=all, retries>0, max.in.flight≤5. KIP-98 связывает records и offsets через sendOffsetsToTransaction; consumer читает read_committed. Платёжный API в гарантию не входит.

AWS Builders’ Library рекомендует caller-provided request ID для повторов одного намерения. Я добавляю unique constraint, состояния IN_PROGRESS/SUCCEEDED и reconciliation неизвестного исхода.

Stripe ограничивает idempotency key 255 символами и может удалить его после 24 часов. После pruning старый retry станет новым запросом. Это контракт Stripe, не закон природы.

Если деньги списались дважды, пользователю до лампочки, насколько красиво exactly-once выглядело внутри Kafka.

#Java #Kafka #идемпотентность

Timeout завершает Future, но не работу

В CompletableFuture легко перепутать завершение обещания и остановку работы. Первое API делает за строку; второе за вас никто, зараза, не спроектирует.

Oracle API: cancel(...) завершает stage через CancellationException, но mayInterruptIfRunning здесь не имеет эффекта — interrupts не управляют обработкой. orTimeout завершает тот же Future через TimeoutException, а completeOnTimeout подставляет значение. Supplier, JDBC-запрос или HTTP-вызов могут продолжать занимать ресурс.

Поэтому я развожу четыре слоя:
— deadline операции;
— timeout реального ресурса;
— cooperative cancellation;
— completion для caller и dependents.

Fallback допустим только как явный бизнес-контракт. TimeoutException у caller и живой JDBC-запрос — не cancellation, а перенос проблемы в мониторинг.

#Java #concurrency #CompletableFuture #reliability