Исторический момент. Новый HTTP-метод в стандарте.
QUERY. Альтернатива GET и POST.
Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.
Только что повышен до Proposed Standard.
👉 Java Portal
QUERY. Альтернатива GET и POST.
Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.
Только что повышен до Proposed Standard.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15
20 законов разработки, которые должен знать каждый инженер
1. Закон Галла: Работающая сложная система вырастает из работающей простой.
2. KISS: Делай проще. Всё остальное — оверхеад.
3. Закон Конвея: Компании проектируют системы, которые повторяют структуру их коммуникаций.
4. Закон Хайрума: У достаточно большого API уже неважно, что ты обещал в контракте. Кто-нибудь уже зависит от каждого observable-поведения твоей системы.
5. CAP-теорема: Выбери два: консистентность, доступность, устойчивость к разделению.
6. Закон Завински: Любая программа разрастается до тех пор, пока не научится читать почту.
7. Закон Брукса: Добавление людей в опаздывающий проект делает его ещё более поздним.
8. Эффект Рингельмана: Производительность каждого участника группы падает с ростом группы.
9. Закон Прайса: Половину работы делают квадратный корень от всех людей.
10. Эффект Даннинга — Крюгера: Новички переоценивают свои способности, эксперты — недооценивают.
11. Закон Хофштадтера: Всё занимает больше времени, чем ты планируешь, даже с учётом этого закона.
12. Закон Паркинсона: Работа расширяется, чтобы заполнить всё отведённое на неё время.
13. Закон Гудхарта: Когда метрика становится целью, она перестаёт быть хорошей метрикой.
14. Закон Гилба: Измерять неточно лучше, чем не измерять вообще.
15. Принцип Кнута: Забудь о микрооптимизациях в 97% случаев. Преждевременная оптимизация — корень всех зол.
16. Закон Амдала: Ускорение одной части системы ограничено долей времени, которое эта часть реально используется.
17. Закон Мёрфи: Если что-то может пойти не так, оно пойдёт не так.
18. Закон Постела: Будь консервативен в том, что отправляешь, и либерален в том, что принимаешь.
19. Закон Стерджена: 90% всего на свете — фигня.
20. Закон Каннингема: Лучший способ получить правильный ответ в интернете — не задать вопрос, а написать неправильный ответ.
👉 Java Portal
1. Закон Галла: Работающая сложная система вырастает из работающей простой.
2. KISS: Делай проще. Всё остальное — оверхеад.
3. Закон Конвея: Компании проектируют системы, которые повторяют структуру их коммуникаций.
4. Закон Хайрума: У достаточно большого API уже неважно, что ты обещал в контракте. Кто-нибудь уже зависит от каждого observable-поведения твоей системы.
5. CAP-теорема: Выбери два: консистентность, доступность, устойчивость к разделению.
6. Закон Завински: Любая программа разрастается до тех пор, пока не научится читать почту.
7. Закон Брукса: Добавление людей в опаздывающий проект делает его ещё более поздним.
8. Эффект Рингельмана: Производительность каждого участника группы падает с ростом группы.
9. Закон Прайса: Половину работы делают квадратный корень от всех людей.
10. Эффект Даннинга — Крюгера: Новички переоценивают свои способности, эксперты — недооценивают.
11. Закон Хофштадтера: Всё занимает больше времени, чем ты планируешь, даже с учётом этого закона.
12. Закон Паркинсона: Работа расширяется, чтобы заполнить всё отведённое на неё время.
13. Закон Гудхарта: Когда метрика становится целью, она перестаёт быть хорошей метрикой.
14. Закон Гилба: Измерять неточно лучше, чем не измерять вообще.
15. Принцип Кнута: Забудь о микрооптимизациях в 97% случаев. Преждевременная оптимизация — корень всех зол.
16. Закон Амдала: Ускорение одной части системы ограничено долей времени, которое эта часть реально используется.
17. Закон Мёрфи: Если что-то может пойти не так, оно пойдёт не так.
18. Закон Постела: Будь консервативен в том, что отправляешь, и либерален в том, что принимаешь.
19. Закон Стерджена: 90% всего на свете — фигня.
20. Закон Каннингема: Лучший способ получить правильный ответ в интернете — не задать вопрос, а написать неправильный ответ.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍4❤2
Kafka в event-driven архитектурах: 5 ключевых паттернов
Большинство разработчиков знают Kafka как систему обмена сообщениями, но мало кто действительно понимает, как использовать всю её мощь в event-driven архитектурах.
Kafka — это не просто продюсирование и потребление сообщений. Это основа масштабируемых, отказоустойчивых и реально-временных систем, используемых крупнейшими компаниями мира.
Вот 5 ключевых паттернов Kafka, которые должен знать каждый инженер:
1. Централизованное управление логами — стримьте логи из нескольких приложений в Kafka для долгосрочного хранения и анализа.
2. Распределение данных в реальном времени — публикуйте данные для множества потребителей эффективно через pub/sub архитектуру Kafka.
3. Бесшовная репликация логов — обеспечивайте консистентность в распределённых системах через репликацию и воспроизведение изменений логов.
4. Многоступенчатая обработка событий — обрабатывайте потоки событий в несколько этапов для обнаружения паттернов и аналитики в реальном времени.
5. Продвинутая автоматизация workflow через события — автоматизируйте процессы, обнаруживая и анализируя паттерны событий в реальном времени.
Освоение этих паттернов поможет проектировать масштабируемые event-driven архитектуры для реальных приложений.
Сохраните этот пост для будущего. Поделитесь с теми, кто готовится к system design интервью или работает с event-driven системами.
👉 Java Portal
Большинство разработчиков знают Kafka как систему обмена сообщениями, но мало кто действительно понимает, как использовать всю её мощь в event-driven архитектурах.
Kafka — это не просто продюсирование и потребление сообщений. Это основа масштабируемых, отказоустойчивых и реально-временных систем, используемых крупнейшими компаниями мира.
Вот 5 ключевых паттернов Kafka, которые должен знать каждый инженер:
1. Централизованное управление логами — стримьте логи из нескольких приложений в Kafka для долгосрочного хранения и анализа.
2. Распределение данных в реальном времени — публикуйте данные для множества потребителей эффективно через pub/sub архитектуру Kafka.
3. Бесшовная репликация логов — обеспечивайте консистентность в распределённых системах через репликацию и воспроизведение изменений логов.
4. Многоступенчатая обработка событий — обрабатывайте потоки событий в несколько этапов для обнаружения паттернов и аналитики в реальном времени.
5. Продвинутая автоматизация workflow через события — автоматизируйте процессы, обнаруживая и анализируя паттерны событий в реальном времени.
Освоение этих паттернов поможет проектировать масштабируемые event-driven архитектуры для реальных приложений.
Сохраните этот пост для будущего. Поделитесь с теми, кто готовится к system design интервью или работает с event-driven системами.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Redis может быть самым большим предательством в истории open source.
В 2009 итальянский разработчик по имени Salvatore Sanfilippo работал над стартапом, а MySQL был слишком медленным. Тогда он в свободное время сделал собственную in-memory базу данных и выложил её в open source бесплатно.
Он назвал её Redis.
Twitter использовал его. GitHub использовал его. Snapchat использовал его. Stack Overflow использовал его. Каждая крупная технологическая компания в мире запускала Redis где-то в своём стеке.
К 2020 году Salvatore выгорел после 11 лет поддержки проекта в одиночку. Он передал проект Redis Labs и ушёл.
В марте 2024 Redis Labs изменили лицензию.
За ночь Redis перестал быть open source. Облачные провайдеры больше не могли предлагать его как managed service без оплаты Redis Labs. Сообщество, которое выросло вокруг кода Salvatore, проснулось и оказалось заблокированным.
Они не спорили. Они не писали посты. Они форкнули проект.
Через восемь дней Linux Foundation объявил Valkey. Поддержка от AWS, Google, Oracle, Ericsson и Snap. Более 50 компаний присоединились за несколько недель.
В течение года Fedora, Ubuntu, Debian и Arch полностью отказались от Redis и сделали Valkey стандартом. AWS перенёс миллионы узлов на Valkey. Valkey достиг 1.19 миллиона запросов в секунду. На 230% быстрее версии Redis, которую прекратили развивать.
Потом Redis вернул Salvatore, чтобы попытаться вернуть сообщество.
Он вернулся. Он выступил на Hacker News, защищая изменение лицензии. Он пытался восстановить доверие.
Сообщество уже двинулось дальше без него.
Redis построил 15 лет доверия в open source. Проверил его один раз. Потерял за 8 дней.
В open source сообщество — это не просто пользователи. Сообщество — это ров.
👉 Java Portal
В 2009 итальянский разработчик по имени Salvatore Sanfilippo работал над стартапом, а MySQL был слишком медленным. Тогда он в свободное время сделал собственную in-memory базу данных и выложил её в open source бесплатно.
Он назвал её Redis.
Twitter использовал его. GitHub использовал его. Snapchat использовал его. Stack Overflow использовал его. Каждая крупная технологическая компания в мире запускала Redis где-то в своём стеке.
К 2020 году Salvatore выгорел после 11 лет поддержки проекта в одиночку. Он передал проект Redis Labs и ушёл.
В марте 2024 Redis Labs изменили лицензию.
За ночь Redis перестал быть open source. Облачные провайдеры больше не могли предлагать его как managed service без оплаты Redis Labs. Сообщество, которое выросло вокруг кода Salvatore, проснулось и оказалось заблокированным.
Они не спорили. Они не писали посты. Они форкнули проект.
Через восемь дней Linux Foundation объявил Valkey. Поддержка от AWS, Google, Oracle, Ericsson и Snap. Более 50 компаний присоединились за несколько недель.
В течение года Fedora, Ubuntu, Debian и Arch полностью отказались от Redis и сделали Valkey стандартом. AWS перенёс миллионы узлов на Valkey. Valkey достиг 1.19 миллиона запросов в секунду. На 230% быстрее версии Redis, которую прекратили развивать.
Потом Redis вернул Salvatore, чтобы попытаться вернуть сообщество.
Он вернулся. Он выступил на Hacker News, защищая изменение лицензии. Он пытался восстановить доверие.
Сообщество уже двинулось дальше без него.
Redis построил 15 лет доверия в open source. Проверил его один раз. Потерял за 8 дней.
В open source сообщество — это не просто пользователи. Сообщество — это ров.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10😁2
Java: Глубокие цепочки вроде
✅
Если
Такой подход читается лучше, чем множество разбросанных
#Java #NullSafety
👉 Java Portal
user → address → city — классическая ловушка для NullPointerException. Вложенные проверки if (x != null) быстро разрастаются, и легко пропустить один из уровней.Optional:findByEmail(email)
.map(User::getAddress)
.map(Address::getCity)
.orElse("unknown");
Если
Optional в API нет, достаточно одной проверки:if (user == null || user.getAddress() == null)
Такой подход читается лучше, чем множество разбросанных
null-проверок, из-за которых сложно понять, какое именно значение может отсутствовать.#Java #NullSafety
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7
Появился проект Build Mini-Kafka — практическое руководство, в котором предлагается с нуля реализовать упрощённую версию Apache Kafka и разобраться в её внутреннем устройстве.
В процессе разработки предстоит реализовать:
- журнал сообщений с моделью append-only и разбиением на партиции;
- выбор лидера на основе алгоритма Raft;
- отслеживание ISR (набора синхронизированных реплик) и продвижение high watermark;
- идемпотентных и транзакционных продюсеров;
- группы потребителей с автоматической перебалансировкой.
Проект ориентирован на изучение принципов работы распределённых брокеров сообщений и архитектуры Kafka через практическую реализацию, а не через теорию.
Ссылка: https://builddistributedsystem.com/projects/mini-kafka
👉 Java Portal
В процессе разработки предстоит реализовать:
- журнал сообщений с моделью append-only и разбиением на партиции;
- выбор лидера на основе алгоритма Raft;
- отслеживание ISR (набора синхронизированных реплик) и продвижение high watermark;
- идемпотентных и транзакционных продюсеров;
- группы потребителей с автоматической перебалансировкой.
Проект ориентирован на изучение принципов работы распределённых брокеров сообщений и архитектуры Kafka через практическую реализацию, а не через теорию.
Ссылка: https://builddistributedsystem.com/projects/mini-kafka
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥1
Spring Cloud: централизуйте конфигурацию с помощью Spring Cloud Config вместо того, чтобы копировать
Используйте Spring Cloud Config для централизованного управления конфигурацией, а не копируйте
#SpringBoot #JavaDev
👉 Java Portal
application.properties в каждый сервис.Используйте Spring Cloud Config для централизованного управления конфигурацией, а не копируйте
application.properties повсюду.// — 1) Config Server: одно место, которое обслуживает конфигурацию всех сервисов —
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApp {
public static void main(String[] args) {
new SpringApplicationBuilder(ConfigServerApp.class).run(args);
}
}
// — 2) application.yml сервера (раздаёт файлы из classpath) —
// spring.profiles.active: native # локальные файлы, Git не нужен
// spring.cloud.config.server.native.search-locations: classpath:/config
// server.port: 8888
// — 3) /config/client-service.yml (конфигурация для "client-service") —
// myproperty: value
// — 4) Клиент: загружает конфигурацию с сервера при запуске —
// spring.application.name: client-service
// spring.config.import: optional:configserver:http://localhost:8888
@Component
public class GreetingClient {
@Value("${myproperty}") // значение получено с Config Server
private String myProperty;
}
#SpringBoot #JavaDev
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
📌 Шпаргалка по API-заголовкам
Заголовки API несут метаданные, обеспечивающие безопасную и эффективную коммуникацию.
- Authorization — отправка токенов доступа безопасно
- Content-Type — определение формата тела запроса
- Accept — указание ожидаемого формата ответа
- User-Agent — идентификация клиентского приложения
- Cache-Control — управление кешированием
- Origin — поддержка валидации CORS
- Cookie — отправка информации о сессии
- Accept-Language — установка языковых предпочтений
Понимание заголовков API помогает создавать более быстрые, безопасные и надёжные приложения.
👉 Java Portal
Заголовки API несут метаданные, обеспечивающие безопасную и эффективную коммуникацию.
- Authorization — отправка токенов доступа безопасно
- Content-Type — определение формата тела запроса
- Accept — указание ожидаемого формата ответа
- User-Agent — идентификация клиентского приложения
- Cache-Control — управление кешированием
- Origin — поддержка валидации CORS
- Cookie — отправка информации о сессии
- Accept-Language — установка языковых предпочтений
Понимание заголовков API помогает создавать более быстрые, безопасные и надёжные приложения.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Java совет : начиная с Java 14 можно использовать
✅ короче обычных POJO
✅ автоматически есть
✅ объекты неизменяемые по умолчанию
👉 Java Portal
record для коротких неизменяемых объектов-носителей данных.✅ короче обычных POJO
✅ автоматически есть
equals(), hashCode(), toString()✅ объекты неизменяемые по умолчанию
Please open Telegram to view this post
VIEW IN TELEGRAM
Как на самом деле работает Git
Большинство использует Git, не понимая, что происходит внутри.
Суть такая:
создаёт папку, за которой Git начинает следить
говоришь Git: «эти изменения пойдут в сохранение»
фиксирует снимок состояния проекта в этот момент
отправляет эти снимки в облако (обычно GitHub)
забирает снимки, которые отправили другие
создаёт отдельную линию разработки, где можно работать изолированно
объединяет эту ветку обратно в основную
👉 Java Portal
Большинство использует Git, не понимая, что происходит внутри.
Суть такая:
git initсоздаёт папку, за которой Git начинает следить
git addговоришь Git: «эти изменения пойдут в сохранение»
git commitфиксирует снимок состояния проекта в этот момент
git pushотправляет эти снимки в облако (обычно GitHub)
git pullзабирает снимки, которые отправили другие
git branchсоздаёт отдельную линию разработки, где можно работать изолированно
git mergeобъединяет эту ветку обратно в основную
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1
Примитивные vs Ссылочные типы в Java
Это одна из самых недопонятых тем в Java.
Многие разработчики знают, что такое примитивные и ссылочные типы, но не то, как они хранятся в памяти.
Понимание этой разницы делает такие темы, как String, Arrays, Objects и Garbage Collection, гораздо более лёгкими для усвоения.
🔹 Примитивные типы
Примитивные переменные хранят фактическое значение.
Примеры:
- byte
- short
- int
- long
- float
- double
- char
- boolean
int age = 25;
double price = 99.99;
char grade = 'A';
boolean isJavaFun = true;
Представьте, что вы пишете число прямо на листе бумаги.
age → 25
🔹 Ссылочные типы
Ссылочные переменные не хранят сам объект.
Они хранят адрес памяти (ссылку) объекта.
Примеры:
- String
- Массивы
- Классы
- Интерфейсы
- Перечисления (Enums)
- Записи (Records)
String name = "Vishwanath";
int[] numbers = {1, 2, 3, 4};
Student student = new Student();
Представьте, что вы храните адрес дома, а не сам дом.
name ───► "Vishwanath"
Простой способ запомнить
- Примитив = хранит значение
- Ссылка = хранит адрес объекта
Совет для собеседования
Что произойдёт здесь?
String a = "Java";
String b = a;
b = "Spring";
Станет ли a тоже "Spring"?
Нет.
b обновляется, чтобы ссылаться на другой объект String, в то время как a всё ещё указывает на исходную строку "Java".
Понимание ссылок объясняет, почему поведение объектов отличается от примитивных значений.
Освоение этой концепции значительно облегчит понимание:
- Stack vs Heap памяти
- Объектов и Классов
- Параметров методов
- Коллекций
- Сборки мусора (Garbage Collection)
👉 Java Portal
Это одна из самых недопонятых тем в Java.
Многие разработчики знают, что такое примитивные и ссылочные типы, но не то, как они хранятся в памяти.
Понимание этой разницы делает такие темы, как String, Arrays, Objects и Garbage Collection, гораздо более лёгкими для усвоения.
🔹 Примитивные типы
Примитивные переменные хранят фактическое значение.
Примеры:
- byte
- short
- int
- long
- float
- double
- char
- boolean
int age = 25;
double price = 99.99;
char grade = 'A';
boolean isJavaFun = true;
Представьте, что вы пишете число прямо на листе бумаги.
age → 25
🔹 Ссылочные типы
Ссылочные переменные не хранят сам объект.
Они хранят адрес памяти (ссылку) объекта.
Примеры:
- String
- Массивы
- Классы
- Интерфейсы
- Перечисления (Enums)
- Записи (Records)
String name = "Vishwanath";
int[] numbers = {1, 2, 3, 4};
Student student = new Student();
Представьте, что вы храните адрес дома, а не сам дом.
name ───► "Vishwanath"
Простой способ запомнить
- Примитив = хранит значение
- Ссылка = хранит адрес объекта
Совет для собеседования
Что произойдёт здесь?
String a = "Java";
String b = a;
b = "Spring";
Станет ли a тоже "Spring"?
Нет.
b обновляется, чтобы ссылаться на другой объект String, в то время как a всё ещё указывает на исходную строку "Java".
Понимание ссылок объясняет, почему поведение объектов отличается от примитивных значений.
Освоение этой концепции значительно облегчит понимание:
- Stack vs Heap памяти
- Объектов и Классов
- Параметров методов
- Коллекций
- Сборки мусора (Garbage Collection)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Эволюция коммуникации между сервисами
Архитектура ПО кардинально изменилась за последние 30 лет.
Не потому, что старые подходы были неправильными..
а потому что приложения постоянно росли.
Вот как развивалась коммуникация сервисов:
🔹 1990-е → Point-to-Point (прямая связь)
Просто. Быстро. Но жёсткая связанность.
🔹 2000-е → Запрос/Ответ (RPC)
Удалённые вызовы упростили построение распределённых систем.
🔹 2010-е → Очереди сообщений (Message Queues)
Асинхронная коммуникация повысила надёжность и масштабируемость.
🔹 Середина 2010-х → Издатель/Подписчик (Pub/Sub)
Сервисам больше не нужно было знать друг о друге напрямую.
🔹 Конец 2010-х → Потоковая обработка событий (Event Streaming)
Непрерывная обработка данных в реальном времени с помощью платформ вроде Kafka.
🔹 2020-е → API Gateway + Service Mesh
Управление трафиком, безопасность, наблюдаемость и отказоустойчивость стали первоклассными гражданами.
🔹 Сегодня → AI-нативная коммуникация
Агенты не просто вызывают API — они обнаруживают инструменты, рассуждают о задачах и координируют рабочие процессы.
Главный урок?
Каждая эволюция уменьшала связанность и увеличивала масштабируемость.
Мы движемся от:
➡️ Вызова сервисов
➡️ Публикации событий
➡️ Координации интеллектуальных систем
Какой паттерн коммуникации вы используете чаще всего сегодня?
- REST
- gRPC
- Kafka
- RabbitMQ
- Event Bus
- Service Mesh
👉 Java Portal
Архитектура ПО кардинально изменилась за последние 30 лет.
Не потому, что старые подходы были неправильными..
а потому что приложения постоянно росли.
Вот как развивалась коммуникация сервисов:
🔹 1990-е → Point-to-Point (прямая связь)
Просто. Быстро. Но жёсткая связанность.
🔹 2000-е → Запрос/Ответ (RPC)
Удалённые вызовы упростили построение распределённых систем.
🔹 2010-е → Очереди сообщений (Message Queues)
Асинхронная коммуникация повысила надёжность и масштабируемость.
🔹 Середина 2010-х → Издатель/Подписчик (Pub/Sub)
Сервисам больше не нужно было знать друг о друге напрямую.
🔹 Конец 2010-х → Потоковая обработка событий (Event Streaming)
Непрерывная обработка данных в реальном времени с помощью платформ вроде Kafka.
🔹 2020-е → API Gateway + Service Mesh
Управление трафиком, безопасность, наблюдаемость и отказоустойчивость стали первоклассными гражданами.
🔹 Сегодня → AI-нативная коммуникация
Агенты не просто вызывают API — они обнаруживают инструменты, рассуждают о задачах и координируют рабочие процессы.
Главный урок?
Каждая эволюция уменьшала связанность и увеличивала масштабируемость.
Мы движемся от:
➡️ Вызова сервисов
➡️ Публикации событий
➡️ Координации интеллектуальных систем
Какой паттерн коммуникации вы используете чаще всего сегодня?
- REST
- gRPC
- Kafka
- RabbitMQ
- Event Bus
- Service Mesh
Please open Telegram to view this post
VIEW IN TELEGRAM
Почему используется Event-Driven Architecture?
Представьте систему с двумя микросервисами:
1) payments
2) emails
Когда платеж подтверждён, payments вызывает emails, чтобы отправить чек.
Но приложение растёт. Теперь нужно ещё сгенерировать счёт, обновить метрики и отправить уведомление.
Чтобы это сделать, payments начинает вызывать каждый из них.
Каждая новая функциональность добавляет ещё один вызов. Со временем такой поток становится всё сложнее поддерживать.
Event-Driven Architecture предлагает другой способ коммуникации.
Когда платеж подтверждён:
1) payments публикует событие "payment confirmed".
2) emails отправляет чек.
3) billing генерирует счёт.
4) metrics обновляет дашборды.
Если завтра вы добавите ещё один микросервис, ему просто нужно реагировать на это событие. Payments не меняется.
Вот почему это так хорошо сочетается с микросервисами: каждый сохраняет единственную ответственность и может развиваться без прямой зависимости от остальных.
Очевидно, не всё только преимущества. Система также становится сложнее. Возникают такие проблемы, как повторные попытки, дублирующиеся события, порядок обработки и наблюдаемость.
На практике обычно используется брокер (например, Kafka или RabbitMQ), который получает событие и распределяет его по подписанным микросервисам.
👉 Java Portal
Представьте систему с двумя микросервисами:
1) payments
2) emails
Когда платеж подтверждён, payments вызывает emails, чтобы отправить чек.
Но приложение растёт. Теперь нужно ещё сгенерировать счёт, обновить метрики и отправить уведомление.
Чтобы это сделать, payments начинает вызывать каждый из них.
Каждая новая функциональность добавляет ещё один вызов. Со временем такой поток становится всё сложнее поддерживать.
Event-Driven Architecture предлагает другой способ коммуникации.
Когда платеж подтверждён:
1) payments публикует событие "payment confirmed".
2) emails отправляет чек.
3) billing генерирует счёт.
4) metrics обновляет дашборды.
Если завтра вы добавите ещё один микросервис, ему просто нужно реагировать на это событие. Payments не меняется.
Вот почему это так хорошо сочетается с микросервисами: каждый сохраняет единственную ответственность и может развиваться без прямой зависимости от остальных.
Очевидно, не всё только преимущества. Система также становится сложнее. Возникают такие проблемы, как повторные попытки, дублирующиеся события, порядок обработки и наблюдаемость.
На практике обычно используется брокер (например, Kafka или RabbitMQ), который получает событие и распределяет его по подписанным микросервисам.
Please open Telegram to view this post
VIEW IN TELEGRAM