Решение важнее пересказа
Ценность технического контента определяется не количеством новостей, а тем, помогает ли он принять инженерное решение. Поэтому здесь важен не пересказ релиза, а его последствия для системы.
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 #архитектура #исследования
Ценность технического контента определяется не количеством новостей, а тем, помогает ли он принять инженерное решение. Поэтому здесь важен не пересказ релиза, а его последствия для системы.
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%.
Это не «победа монолита»: речь об одном тесно связанном workflow. Моя исходная позиция — модульный монолит. Сервис выделяется, когда есть самостоятельная бизнес-граница и измеримое эксплуатационное давление.
#Java #архитектура #микросервисы
Микросервисы обещают независимые релизы, масштабирование и изоляцию отказов. Но каждая такая граница добавляет сетевые вызовы, распределённое состояние и эксплуатационную координацию.
Дэвид Парнас предлагал отделять модуль там, где он скрывает независимо меняющееся решение. Отдельный процесс нужен позже — когда независимость должна дойти до релиза, scaling или failure domain.
DeathStarBench 2019 собрал 6 end-to-end приложений: benchmark одного процесса не видит service graph и tail latency системы. В кейсе Prime Video прежний workflow упёрся примерно в 5% ожидаемой нагрузки; после локальной консолидации команда сообщила о снижении инфраструктурной стоимости на 90%.
Это не «победа монолита»: речь об одном тесно связанном workflow. Моя исходная позиция — модульный монолит. Сервис выделяется, когда есть самостоятельная бизнес-граница и измеримое эксплуатационное давление.
#Java #архитектура #микросервисы
Транзакция должна заканчиваться раньше сети
Транзакция сохраняет инвариант: изменение фиксируется целиком либо не фиксируется. Проблема начинается на границе базы, HTTP и broker.
По Spring Framework, @Transactional действует только в границе TransactionManager; HTTP и обычная отправка в broker туда не входят.
Три детали, которые ломают уверенность:
— self-invocation в proxy mode не перехватывается;
— checked exception по умолчанию не вызывает rollback;
— PostgreSQL принимает 4 названия isolation level, но реализует 3 режима: READ UNCOMMITTED работает как READ COMMITTED.
В READ COMMITTED каждый SELECT начинает новый snapshot. По документации PostgreSQL serialization failure — SQLSTATE 40001, deadlock — 40P01; повторять нужно всю транзакцию.
Для DB + broker данные и outbox фиксируются вместе. Debezium connector читает изменения через CDC, а Event Router преобразует запись перед публикацией. Дубликаты возможны, поэтому consumer остаётся идемпотентным.
#Java #Spring #транзакции
Транзакция сохраняет инвариант: изменение фиксируется целиком либо не фиксируется. Проблема начинается на границе базы, HTTP и broker.
По Spring Framework, @Transactional действует только в границе TransactionManager; HTTP и обычная отправка в broker туда не входят.
Три детали, которые ломают уверенность:
— self-invocation в proxy mode не перехватывается;
— checked exception по умолчанию не вызывает rollback;
— PostgreSQL принимает 4 названия isolation level, но реализует 3 режима: READ UNCOMMITTED работает как READ COMMITTED.
В READ COMMITTED каждый SELECT начинает новый snapshot. По документации PostgreSQL serialization failure — SQLSTATE 40001, deadlock — 40P01; повторять нужно всю транзакцию.
Для DB + broker данные и outbox фиксируются вместе. Debezium connector читает изменения через CDC, а Event Router преобразует запись перед публикацией. Дубликаты возможны, поэтому consumer остаётся идемпотентным.
#Java #Spring #транзакции
Exactly-once не отменяет бизнес-идемпотентность
Идемпотентность нужна, чтобы retry не превращался в повторный платёж, заказ или списание. Но exactly-once транспорта не гарантирует однократный эффект во внешней системе.
Документация 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, не универсальный TTL.
#Java #Kafka #идемпотентность
Идемпотентность нужна, чтобы retry не превращался в повторный платёж, заказ или списание. Но exactly-once транспорта не гарантирует однократный эффект во внешней системе.
Документация 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, не универсальный TTL.
#Java #Kafka #идемпотентность
👋 Добро пожаловать в Java && Management
Здесь — практические разборы Java/JVM, архитектуры, Kafka, эксплуатации и инженерного управления: первичные источники, актуальные релизы, диаграммы и выводы для решений.
Навигация:
• #Java — JVM, Spring и платформенные изменения
• #Kafka — очереди, события и идемпотентность
• #идемпотентность — retry, консистентность и надёжность
• комментарии — вопросы и разборы в связанном чате
Нужен независимый технический аудит Java/backend, инфраструктуры или интеграций?
→ https://krot.name/
Профили и кейсы: https://krot.name/profiles/
Здесь — практические разборы Java/JVM, архитектуры, Kafka, эксплуатации и инженерного управления: первичные источники, актуальные релизы, диаграммы и выводы для решений.
Навигация:
• #Java — JVM, Spring и платформенные изменения
• #Kafka — очереди, события и идемпотентность
• #идемпотентность — retry, консистентность и надёжность
• комментарии — вопросы и разборы в связанном чате
Нужен независимый технический аудит Java/backend, инфраструктуры или интеграций?
→ https://krot.name/
Профили и кейсы: https://krot.name/profiles/
Андрей
Технический аудит Java/backend: риски, сбои и план работ
Аудит Java/backend, инфраструктуры и интеграций для CTO, владельцев продукта и руководителей ИТ.
Java && Management pinned «👋 Добро пожаловать в Java && Management Здесь — практические разборы Java/JVM, архитектуры, Kafka, эксплуатации и инженерного управления: первичные источники, актуальные релизы, диаграммы и выводы для решений. Навигация: • #Java — JVM, Spring и платформенные…»
