Недавно в регионе US-EAST-1 у AWS были сбои.

Как бы ты спроектировал деплой микросервиса и инфраструктуру вокруг, чтобы пережить падение одной инстансы, сбой базы данных или даже отказ целого дата-центра ?

Когда делаем систему с высокой доступностью, нужно сразу исходить из того, что все рано или поздно ломается. Поэтому закладываем автоматическое восстановление на каждом уровне.

Держим несколько одинаковых инстансов сервиса за нагрузочным балансировщиком. Деплоим их в разные зоны. Если одна инстанса упала, балансировщик просто перестает слать ей трафик и направляет запросы на оставшиеся живые экземпляры.

Для базы данных используем репликацию. Есть primary и хотя бы одна hot-standby реплика в другой физической зоне. Все записи в primary сразу копируются на standby.

Практикуем Chaos Engineering: намеренно ломаем часть продовой инфраструктуры, например, убиваем сервисы или добавляем сетевые задержки. Смотрим, что автоматический failover реально срабатывает как задумано, а не только на бумаге.

👉 Java Portal

Видишь разницу между этими двумя кусками кода? 👀

На первый взгляд делают одно и то же, но…

В первом варианте все классы вынуждены реализовывать методы, которые им вообще не нужны.

Во втором интерфейсы разделены: каждый класс берет только то, что реально использует.

Принцип разделения интерфейсов (ISP)

👉 Java Portal

🔍Тестовое собеседование с ТехЛидом из МТС уже завтра

5 ноября(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика.

Как это будет:
📂 Илья Аров, старший разработчик в МТС, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Илья будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Илье

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot

Реклама.
О рекламодателе.

Не все данные обрабатываются одинаково. Понимание, когда подходит batch, а когда stream, решает, получится ли у тебя нормальная архитектура или скрытый тормоз внутри.

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

Он проще, нормально тянет большие объемы и дешевле по деньгам,
но появляется задержка. Событие уже случилось, а ты обрабатываешь его потом.

Stream Processing работает с данными прямо в потоке.

Отлично для мониторинга, антифрода, рекомендаций в реальном времени.

Скорость выше, но инфраструктура сложнее и поддержка дороже.

Часто косячат: ставят stream там, где батча за глаза, или наоборот, лепят batch туда, где важна минимальная задержка.

Фишка не в том, чтобы выбрать самое модное, а в том, чтобы попасть в реальный ритм бизнеса и решить конкретную задачу.

А если ресурсы сильно ограничены, скорее всего, batch уже закрывает потребности.

👉 Java Portal

Совет по Java: начиная с Java 8 можно легко убирать null значения с помощью list.removeIf(Objects::isNull)

👉 Java Portal

🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Москве и поборись за призовой фонд 1 200 000 рублей!

Когда: 25–28 ноября
Формат: онлайн + финал на площадке

Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности
🔹развиваешься в направлении разработки, системной администрации, AI/ML или DevOps
🔹сможешь быть в Москве 28 ноября.

Выбери свой кейс:

✴️VibeCode Jam: собеседование будущего. Создай ИИ-платформу для прохождения технических собеседований с виртуальным интервьюером.

✴️Self-Deploy: CI/CD без DevOps. Автоматизируй генерацию CI/CD пайплайнов по анализу структуры Git-репозитория.

Почему стоит участвовать:
🔘Кейс в портфолио и полезная обратная связь от менторов Т1
🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний
🔘Реальный опыт командной работы
🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.

Регистрация открыта!
➡️ Успей до 23 ноября по ссылке.

Реклама.
О рекламодателе.

Совет по Docker

Как понять, что раздувает образ

Любой Docker-образ состоит из слоев.
Каждая строка в Dockerfile добавляет новый слой.

По этим слоям можно понять, почему образ получается большим, долго собирается или плохо кешируется.

Вот как посмотреть слои и узнать, что именно менялось в каждом из них.

Используй утилиту dive.

Она показывает наглядно:

- какие слои созданы
- какие файлы добавлены или изменены
- сколько места занимает каждый слой

Когда начинаешь изучать слои образа, можно быстро выяснить:

• какая команда в Dockerfile добавляет лишний вес
• как оптимизировать сборку, чтобы образ был меньше и собирался быстрее

Dive также дает оценку «эффективности» образа. Она показывает, насколько много данных дублируется или просто впустую занимает место в слоях.

👉 Java Portal

Java/Backend. Интервью. Сценарный вопрос про распределенный лок:

У тебя есть критичный сервис, допустим обработка заказов, который крутится на нескольких инстансах в Kubernetes. Чтобы избежать гонки, когда два инстанса одновременно берут один и тот же заказ, ты ставишь распределенный лок через Redis setnx с TTL 10 секунд.

Какой критичный кейс все равно возможен, если один из инстансов словит Full GC паузу длиной 15 секунд сразу после получения лока? Опиши ситуацию split-brain и к чему она приведет по данным.

Как это разруливать на интервью:

→ сначала важно отметить, что простой Redis-лок с TTL помогает, если сервис просто упал, но создает новую, куда более опасную проблему

→ баг в том, что длинная пауза, например Full GC, может быть дольше, чем TTL лока

→ и вот что ломается (Split-Brain):

Service A берет лок,
и тут же уходит в GC на 15 секунд

Через 10 секунд Redis удаляет лок по TTL

Service B спокойно берет тот же лок,
и начинает обрабатывать заказ

Через 15 секунд Service A просыпается
все еще уверенный, что лок у него
и тоже обрабатывает этот же заказ

→ итог: два сервиса одновременно трогают один и тот же заказ. Данные ломаются. Например клиенту списывают деньги дважды.

→ реальное решение (меняем дизайн): вообще избавиться от лока

Кладем заказы в очередь сообщений,
например Kafka или RabbitMQ

Consumer group с несколькими инстансами читает этот топик

Брокер гарантирует, что каждое сообщение (заказ) уходит только одному инстансу из группы

👉 Java Portal

Учебник по Java от Андрея Иванцова теперь доступен онлайн на GitBook. В нём собрано всё, что нужно новичку: от простых типов данных и строк до исключений и коллекций. Материал подан по делу, с примерами кода и понятными объяснениями.

Ссылка для тех, кто хочет прокачаться: andrey-ivantsov.gitbook.io/java

👉 Java Portal

Совет по Spring Boot 4. В Jackson 3 теперь в приоритете JsonMapper для работы с JSON. Обрати внимание на новый import. ObjectMapper из com.fasterxml больше не нужен. JsonMapper теперь основной инструмент для JSON в современных Spring-приложениях.

👉 Java Portal

Зарплата 207.000р у Middle-разработчика в Яндекс

«В день уходит несколько часов на созвоны, в остальное время закрываю задачки из спринта, редко перерабатываю. У компании топовый офис, но с коллективом как-то не заладилось. Радуюсь классному ДМС и стабильной зарплате» - middle разработчик из Яндекса.

Бигтех по-русски - канал с реальными зарплатами и историями IT-специалистов российского БигТеха. Там уже опубликованы рассказы программистов Альфа-банка, Сбера и Тинькофф 🤯

Читайте: @bigtech_russia