Що таке ідемпотентність❓

Цього тижня буду багато писати про розподілені системи та підходи, які часто в них використовуються. Почну з одного з найважливіших понять у мікросервісах - ідемпотентності. Це властивість операції, за якої її повторне виконання має такий самий кінцевий результат, як і одноразове виконання.

Найпростіший шлях - розібрати цю концепцію на прикладі REST API, оскільки семантика HTTP чітко описує методи відносно ідемпотентності.

При багаторазовому виклику методів GET, PUT, DELETE стан системи буде таким самим, як і при одноразовому виклику. Тоді як метод POST змінює стан системи, створюючи нову сутність при кожному виклику.

В розподілених системах ми маємо опрацьовувати різні сценарії, де ідемпотентність відіграє ключову роль:
- Timeouts можуть провокувати повторні запити;
- Брокери повідомлень з at least once гарантією доставки можуть дублювати повідомлення;
- Операції можуть виконуватися повторно через retry-механізми;
- Нестабільність системи може запускати повторне опрацювання розподілених транзакцій;

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

Що таке гарантії доставки?

Це одне з найважливіших понять у брокерах повідомлень. Воно визначає, як повідомлення поводитимуться в ланцюжку producer → broker → consumer, а також описує їхню поведінку в разі збоїв системи.

Частіше всього, використовують три рівні гарантій доставки:

At most once - практично виключає дублікати, але повідомлення може загубитися при збоях в системі.

At least once - найпоширеніша гарантія доставки. Повідомлення може дублюватись, якщо брокер не отримав acknowledgement тому consumer повинен бути ідемпотентним (дивись допис вище up⬆️).

Exactly once - повідомлення буде оброблене рівно один раз. У теорії звучить добре, але на практиці реалізація потребує значних зусиль, тому використовується нечасто. Технічно це зазвичай досягається комбінацією at least once і ідемпотентної обробки в задіяних вузлах.

Зламали улюблену бібліотеку frontend молодьожі - TanStack😱

Останнім часом, дуже часто ламають frontend інструменти і як на мене єдиний спосіб вберегти себе від цього - переходити в backend.

📎 - https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

Трохи про танці: Оркестрація vs Хореографія

Ця тема доволі проста, але важлива для розуміння того, як відбувається взаємодія компонентів у розподілених системах.

Оркестрація
В цьому підході ми створюємо додатковий сервіс, який керує всім процесом і транзакціями. Головний плюс такого підходу - це те, що все знаходиться в одному місці, і працювати чи дебажити набагато простіше, ніж в хореографії.

Це, звісно, створює вузькі місця, і оркестратор може стати god service, що суперечить основній концепції Microservices - Loose coupling.

Хореографія
Тут в нас немає центрального сервісу, який керує всім процесом. Кожен сервіс розуміє, як йому відреагувати на конкретну подію та куди "відкотити" транзакцію у разі збою.

З плюсів такого підходу - це простота і менша звʼязаність сервісів. Але якщо логіка ускладнюється, це часто перетворюється на хаос.

В реальності найчастіше використовують гібридний підхід. Для звичної взаємодії між сервісами використовується хореографія, а для складних flow - оркестрація.

Що почитати по АІ?
Знайшов непогану книжечку про Agentic AI. Я тільки почав її читати і в цілому виглядає доволі непогано. Тут немає якихось революційних тем і для мене це більше рефреш і закріплення тем, які потрібно розуміти при роботі з будь яким агентним фреймворком по типу LangGraph.

З плюсів, які можу підкреслити зараз - це детальний опис тем і багато прикладів. Разом з тим книга читається доволі просто.

Рекомендую всім розробникам, які планують розширювати експертизу в АІ.

📎 - https://github.com/DanieleSalatti/AgenticDesignPatterns/tree/main

Ловіть ще одну Job board де публікують реальні вакансії. Постять їх не часто, але якщо ви маєте EU ФОП і працюєте в backend/full-stack - це буде +1 місце де шукати роботу.

https://www.jobs.nestjs.com/

+1 ресурс по АІ. Я не використовував, але теми виглядають цікавими⬇️⬇️⬇️

https://learn.deeplearning.ai/

А не користувались цим ресурсом? Бачу його часто в лінкедин радять. Дивлюсь там навіть скіл білдер є, який роадмап тобі може сформувати

В тему розподілених систем
Згадав, що в мене є цікава книга по ним. Я читав її років 6 тому, але на мою думку вона не втратила своєї актуальності

Гарно підійде для тих, хто тільки починає знайомитись з мікросервісами або хоче освіжити знання по основним підходам в розробці

Уявіть, вам стирають памʼять і ви можете переглянути цей шедевр ще раз 😁

https://www.youtube.com/watch?v=jj2TXJtzBQw&list=PLB86E02CE3735E3B6

Натрапив на цікавий проект - Floci

Фактично - це локальний емулятор AWS сервісів. На перший погляд він виглядає як LocalStack для бідних, так як підтримка сервісів дуже обмежена, але безкоштовно 😁

Як на мене, підійде тільки для чогось маленького, так як підтримка сервісів бідова і є велика імовірність впертись в обмеження Floci.


📎 - https://github.com/floci-io/floci

Попалось цікаве відео від каналу IBM, про RAG

В цілому, нічого нового чи магічного, але для тих хто тільки почав знайомитись з AI в розробці буде цікаво

📎 - https://www.youtube.com/watch?v=UabBYexBD4k

Security в WEB

Так як рівень API чи Frontend - це зазвичай відповідальність інженерів, потрібно розуміти основні болячки в безпеці.

Як на мене, найкращий ресурс - це OWASP Top 10. Тут зібрані найбільш критичні вразливості на поточний період (останній репорт за 2025).

Цей ресурс важливий не тільки для роботи, а і для проходження інтервʼю, як в наших, так і забугорних компаніях. Тому якщо ти шукаєш новий проект, обовʼязково ознайомся на базовому рівні.

Поки інфоцигани продають курси з АІ непотребом, по типу N8N, LangChain запустили свою академію де можна безкоштовно розібратись з LangChain, LangGraph i LangSmith.

Здебільшого курси використовують Python SDK, але також є TS. Я вже давно слідкую за ними і TypeScript SDK дуже гарно розвивається і цілком production ready, що в рази спрощує інтеграцію АІ в продукти де використовується Node.js.

📎 - https://academy.langchain.com

Одна з причин чому я використовую JetBrains IDEs - це наявність всіх інструментів з коробки, без необхідності встановлювати плагіни сумнівної якості 😈

Чи треба розуміти Big O Notation?😱

Це доволі холіварна тема, але, як на мене, якщо ви Middle чи вище, то загальне розуміння Big O все ж потрібне. І ось чому.

Краще бачення системи
Ми щодня працюємо з різними інструментами: cache, message brokers, databases... Розуміння ефективності структур даних допомагає краще бачити, коли і яку структуру варто використовувати.

Співбесіди 😁
Big O часто питають у різних контекстах. Іноді просять оцінити складність рішення під час лайвкодингу, тому для інтервʼю з цим все одно доведеться розібратися на базовому рівні.

Ефективний код
Усі ми пишемо гівнокод - хоча з приходом AI, він став трохи кращим. Але іноді доводиться вирішувати не зовсім тривіальні задачі. Наприклад, паралельно обробити велику кількість даних.

У такому випадку від ефективності вашого коду може залежати, скільки машин доведеться запустити для цієї задачі і, відповідно, скільки ви за них заплатите.

Доречі, якось писав про це на сайті

Додав нове відео на канал 🔥

У ньому розповів про ідею індексів і про те, як вони прискорюють пошук. Також розібрав кілька типів індексів: B-Tree, Hash, Vector - і висвітлив основні підводні камені, які трапляються під час використання індексів.

📎 - https://youtu.be/gBauJAfvBSo?si=Or_FvIwzph9zOimJ

Є дві пляшки книги

Вони написані дуже давно, і більшість розробників про них чули - це Чистий код і Чиста архітектура. Чи пережили вони випробування часом?

Як на мене, Чистий код - однозначно ні.

Інфляція коду почалася ще задовго до АІ, кодити ставало все простіше, а фреймворків і бібліотек - усе більше. З появою АІ код знецінився ще сильніше. Тому, якщо ви планували читати цю книгу, краще зосередьтеся на більш системних речах.

А от із книгою Чиста архітектура усе цікавіше.

Мені здається, вона пережила випробування часом і залишається однією з тих книг, які варто прочитати кожному розробнику. Все таки архітектура - це про вміння бачити систему, розділяти відповідальність, керувати залежностями і розуміти наслідки своїх рішень для продукту

Це завжди цінувалось набагато більше, ніж вміння писати код (за нього вже давно ніхто не платить).

В кого які думки з цього приводу?

+1 рекомендація. Я не читав, але @yurarrr поганого не порадить⬇️

оця варта уваги

Згадав про одну цікаву книжку, яка скрасить вашу поїздку в поїзді чи літаку📕

Чудово підійде в якості поверхневого огляду різних архітектур, варіантів їх розвитку і їхніх болячок, які виникають в процесі еволюції продукту.

Також, непогано підійде для підготовки до system design interview і в цілому підніме рівень проходження інервʼю.

З найцікавішого, можна виділити:
- Fitness Functions
- Evolutionary Architecture Pitfalls and Antipatterns
- Architectural Coupling

З мінусів, це поверхневість книги, що в принципі не дивно, бо вона доволі тонка