From A | Все про IT

Простими словами про патерни. Сьогодні про Service Discovery. В онлайн-грі список кентів показує, хто зараз онлайн - хтось зайшов, вийшов, список оновлюється сам. Service Discovery - такий же живий реєстр: знає, які сервіси працюють і за якою адресою. У хмарі чи кубіку адреси сервісів(IP/порт) постійно змінюються - сервіси стартують, падають, масштабуються. Статичний список адрес не варік: клієнт має щоразу знайти живий екземпляр. Робимо реєстр сервісів - живу базу екземплярів та їх адрес. Екземпляри реєструються самі і шлють heartbeat-и; реєстр кікає мертвих. Клієнт питає реєстр і дістає лише здорові екземпляриі і балансує між ними. Тіки-но з'являються нові репліки, клієнти бачать їх автоматично, без зміни конфігурації. Існує два стилі: • client-side - клієнт запитує реєстр і балансує; • server-side - за нього це робить балансувальник або DNS. Реєстр - критична інфраструктура: без HA(хай евейлабіліті) його падіння зупиняє все виявлення.

Ітак откриваю нову рубріку : айтішні кошмари. Сьогодні наснилось шо здаю екзамен по структурам даних і жостка фейлю на самих тупих питаннях. А чи снились вам айтішні кошмари? Цікаво стало

Простими словами про патерни. Сьогодні про API Gateway. Заходиш у лікарню - не бігаєш сотнею кабінетів, а йдеш до реєстратури, і вона скеровує куди треба. API Gateway - ті самі єдині двері: клієнт стукає раз, а шлюз розкидає запит по сервісах. Різні клієнти без АРІ гейтвею вони будуть викликати десятки дрібних сервісів. Клієнт мусить знати їхні адреси, робити купу мережевих ходів і зшивати відповіді сам. Ставимо перед сервісами API Gateway - єдину точку входу. Він: • маршрутизує запити до потрібних сервісів; • агрегує кілька відповідей в одну; • транслює протоколи (REST → gRPC); • бере на себе: автентифікацію, TLS, ліміти, логування. Клієнт робить один виклик - внутрішня декомпозиція лишається невидимою за стабільним контрактом. Варіант BFF: окремий шлюз під кожен тип клієнта. Не кладемо в шлюз бізнес-логіку - стане новим монолітом. І тримаємо його stateless у N репліках: він на критичному шляху кожного запиту. #мікросервіси #архітектура #systemdesign #microservices #apigateway #api #патерни

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

У мене часто вживалось слово - компенсаторна подія Уявіть, що банк помилково зняв з вашого рахунку 30 грн: у журналі вже є подія ЗНЯТЬ_БАБЛО(30). У звичайній базі ви б просто виправили число або видалили рядок. В event sourcing так робити не можна - журнал append-only, історію не переписують. Тож помилку виправляють так само, як у бухгалтерії - дописують у кінець журналу нову подію, яка скасовує попередню. Наприклад, ПОВЕРНУТИ_БАБЛО(30) (повернення помилково знятих 30 грн). Після згортки баланс знову вірний, але в історії видно і помилку, і її виправлення - хто, коли і чому. Саме це і є компенсаторна подія: "виправлення" записане як ще один факт, а не як редагування минулого. Це та сама ідея, що й компенсаційні транзакції в Saga - не "відкотити", а "зробити протилежну дію".

Простими словами про патерни. Сьогодні про Event Sourcing. Інколи хотілось би відмотати час назад та деякі речі відтворити знову. Наприклад купити біткоїни. Event Sourcing - саме про це: сервіс тримає не "як зараз", а весь список подій і щоразу вираховує стан із них. Класичне сховище зберігає лише поточний стан і затирає, як ми до нього дійшли. Історія, аудит, "а що було у минулий вівторок?" - усе втрачено назавжди. Рішення: зберігаємо не стан, а послідовність подій, що його змінюють. Сховище подій - append-only: події незмінні, їх лише дописують. Поточний стан обчислюють, згортаючи (fold) події агрегату; Ну і для оптимізації робимо знімки (snapshots) які пришвидшують відтворення. Події - це наше єдине джерело істини. Тож будь-яку модель для читання можна перебудувати, просто відтворивши журнал. Бонус - запити по часу: відтворити стан на будь-який момент у минулому. "Виправлення" - це нова компенсаторна подія, а не редагування старої. І звінсо плануємо еволюцію схеми: старі події треба вміти читати завжди (версіонування/upcasting). #мікросервіси #архітектура #systemdesign #microservices #data #eventsourcing #патерни

які часи такі і подарунки

Простими словами про патерни. Сьогодні про CQRS. На екзамен ти маєш товстий зошит, де все записано ретельно і окрему шпаргалку з готовими відповідями. Шпаргалку не редагуєш напряму. CQRS це приблизно так само: одна модель для запису, окрема швидка модель для читання. Чому? Бо одна модель даних рідко добре служить і записам, і читанням. Запис хоче нормалізації та інваріантів; читання — інколи денормалізованих форм під конкретний екран. А крос-сервісні запити через JOIN за приватними базами взагалі неможливі. Рішення: розділити відповідальність. - Командна сторона обробляє CUD, дотримується інваріантів і публікує події. - Запитна сторона тримає одну чи кілька читальних моделей - денормалізованих вьюшок, зібраних із цих подій саме під потрібні запити. Читальну модель ніколи не змінюють напряму. Головний виграш - читання й запис масштабуються незалежно, а читальна модель відповідає навіть на крос-сервісні запити. Оновлення асинхронне(eventual consistency): читання можуть відставати. #патерни

Свіже повітря, 7000 айтівців і благодійний пікнік 🧃 5 вересня DOU влаштовує найбільший невимушений нетворкінг в українському ІТ — DOU Day Picnic. 👉 На вас чекають велика сцена з топовими спікерами, фудкорт, зони для чілу, стендап Васі Байдака, концерт, майстерки, барахолка й десятки способів провести день без напрягів, познайомитись з людьми з індустрії та підтримати армію. Приходьте з дітьми — для них буде окрема програма. Хвостиків теж беріть із собою: DOU Day Picnic — pet-friendly 🐶🐱 🎟 Вхід — за донат: 1000 грн 💸 100% вартості квитків перекажемо на наш збір на бомбери VAMPIRE для «Хартії». Купити квиток: https://dou.ua/goto/picnic

Як же бісить коли комусь задаєш одне просте питання і очікуєш відповідь у boolean, а тобі висирають string на 50 000 символів.

Тоже так ?

🟢Цікаві пропозиції від UPSTARS🟢 UPSTARS – продуктова IT-компанія, з якою злітають і люди, і бренди. Команда створює технологічні рішення та B2B-сервіси для міжнародних клієнтів. Ваша наступна роль може починатися з цього допису: 🔹 Senior Security Engineer (SecOps) 🔹 Senior Atlassian Administrator 🔹 Senior Ruby Engineer 🔹 Senior Product Owner 🔹 Middle Business Development Manager Відчуваєш метч? Нумо знайомитися ✨ Talent Network | Career | Карʼєрний сайт

Простими словами про патерни. Сьогодні про сагу. Уяви: ти зібрав відпустку по кусочках - квиток, готель, авто напрокат. Готель зірвався і ти не летиш "в нікуди", а скасовуєш квиток і повертаєш гроші за авто. Saga - це операція з кроків, де для кожного заздалегідь відомо, як його скасувати, якщо далі щось зламалось. Більш технічно: Нехай бізнес-операція охоплює кілька сервісів- наприклад, оформлення замовленні в якому приймають участь Orders, Payments та Inventory сервіси. У кожного власна база, спільної ACID-транзакції немає(бо бази рінзі), а 2PC(двофазний коміт) блокує ресурси й погано масштабується. Рішення: реалізуємо транзакцію як послідовність локальних. Кожен крок оновлює один сервіс і запускає наступний. Якщо крок падає - сага виконує компенсаторні транзакції у зворотному порядку: не "прибрати списання", а зробити refund. Є два стилі координації: - хореографія - аналогія балет - сервіси реагують на події одне одного; - оркестрація - аналогія дирижер - існує центральний оркестратор який шле команди й стежить за відповідями. Сага завжди завершується в узгодженому стані: або всі кроки пройшли, або виконані скасовано компенсаціями. (!) У саги немає ізоляції - інші операції бачать проміжні стани. Кроки і компенсації мають бути ідемпотентними (Inbox) і надійно публікуватися (Outbox). #мікросервіси #архітектура #systemdesign #microservices #distributedsystems #патерни

https://x.com/unclebobmartin/status/2080257779395154409 ну всьо. дядя боб трошки того.. перегрелся. дідууу, таблетки пий давай!

Claude Code on desktop now works with the iOS simulator. Build and run your iOS app, and the simulator opens in a panel right next to your conversation. Available today in public beta

Простими словами про патерни. Сьогодні про inbox. Буває, телефон через глюк надсилає те саме повідомлення двічі. Друг просить перекинути за піцу - повідомлення прийшло двічі, але платиш ти один раз, бо помітив шо «це ж вже було!». Inbox - це коли сервіс так само запам'ятовує ID повідомлення й на дубль більше не ведеться, як ти на манупуляції колишньої. Inbox (Idempotent Consumer) Брокери гарантують at-least-once: одне й те саме повідомлення може прийти повторно (relay перепублікував, споживач упав до ack, перебалансування партицій). Наївний споживач "отримав - виконав" надішле другий лист, а якийсь Payments сервіс спише гроші двічі. Рішення Робимо споживача idempotent. Два шляхи: 1) природна ідемпотентність: UPSERT замість INSERT, "встановити стан" замість інкремента. Тут окреме сховище не потрібне. Прикладами можуть бути оновлення статусу замовлення. 2) таблиця inbox: перед обробкою пишемо стабільний message_id у тій самій транзакції, що й бізнес-зміну. Тоді дублікат порушить унікальне обмеження й тихо відсіється. Тут приклади це списання коштів, зміни у зовнішніх системах, і т.д. Найкращий ID для дедуплікації - це id рядка outbox-у. Тоді Outbox + Inbox дають ефект «exactly-once» без розподілених транзакцій. Ну і як в outbox-і, не забувайте про очистку бази. #мікросервіси #архітектура #systemdesign #microservices #data #messaging #патерни

🔥 Добірка крутих можливостей для QA джунів Продуктова компанія Quarks (роблять high-load продукти у сфері social discovery & relationsip wellness) має одразу три вакансії для початківців. А робота в продукті — це завжди +100 до скілів, бо завдання різноманітні, а результати твоїх тестів впливають на мільйони реальних юзерів • Junior QA Engineer https://cutt.ly/Oyr7Zjfp • Junior Manual QA https://cutt.ly/1yr7ZHku • Junior QA Engineer https://cutt.ly/Kyr7Z5V7 💰 Бонус для тих, хто не шукає роботу: якщо у вас є талановитий знайомий джун, рекомендуйте та отримаєте $300 за успішний найм: https://cutt.ly/pyr7XsXz

Смаріте краще документалку про джаву в ріалтаймі https://youtu.be/ZqGSg4b_cZA?is=dzuKoCWbazoj1xoC

Простими словами про патерни. Сьогодні про outbox. уяви: пообіцяв другові скинути рілсік, але телефон сів, тасок накидали - і забув. відосік не дійшов, друг у сумнівах щодо твоєї орієнтації. На технічній: сервіс зберіг замовлення в базі і має надіслати івент у брокер. якщо процес упаде між commit і publish, дані є, а івенту немає (або навпаки) - це проблема подвійного запису. Рішення: пишемо подію в ту саму транзакцію - в окрему таблицю outbox. замовлення і подія фіксуються атомарно: або обидва, або жоден. далі relay (полінг або CDC) читає нові рядки, публікує в брокер і позначає надісланими. івент переживе недоступність брокера - бо чекає у таблиці. головне: outbox дає at-least-once, не exactly-once. relay може опублікувати івент і впасти до того, як позначив рядок - після рестарту опублікує вдруге. тому консюмери мають бути ідемпотентними. порядок гарантується лише якщо relay публікує послідовно чи партиціонує по aggregate_id. і чисть надіслані рядки, інакше таблиця росте як твій беклог. #патерни

бляха я начінаю уже гореть із цього оверрелайансу на аішку. люди почали її ЗАНАДТО абьюзити уже. 3-и роки назад всі такі "не, хуйня ваша ця аішка, я краще , бла-бла-бла". люди зараз — не читають, блять, тред в слаку і просто тупо проксірують відповідь клоду шоб він за них УЖЕ БЛЯТЬ В СЛАКУ ВІДПОВІВ. це якийсь закат інженерії уже почався? ріл. якшо ваша робота зводиться до копіювання з одного місця і вставляння в інше - блять ви не інженер а кусок гамна який надо змити в унітаз. прастіті. нада було виговоріться. всім терпіння та розуму.