TGViewer
ИТ-архитектура ИТ-архитектура @itarchitecture · 558 subscribers
Post #244 687

Forwarded from VM

Монолит vs Микросервисы

Я тут пока рассказывал ребятам про pet-проекты крутые, то столкнулся с популярным вопросом на тему того, как мне лучше сделать: все фичи в одном проекте или разбивать на микросервисы? Дескать микросервисы – это хайповая тема, которую хотят в вашем CV все рекрутеры и прочее

В общем когда вы делаете именно pet-проект, то все зависит от вас в общем-то: что вы там хотите изучить, что хотите показать другим людям. Но я бы сказал, что если вы стартанете свой стартап или в принципе какой-то проект с нуля, который будете делать “для себя”, то начинайте лучше с монолита.

Почему? Потому что это гораздо проще разрабатывать. Вы по сути просто пишите код и реализуете фичи, а значит быстрее получаете результат. Как только вы начинаете городить микросервисы просто потому, что они модные, то у вас сразу появляются проблемы:

- Как грамотно разбить вашу логику на отдельные компоненты?
- Какой способ коммуникации между ними использовать?
- Нужно реализовывать механизм retry между сервисами при прерывании коммуникации
- Где хранить данные? У каждого отдельная БД? А куда тогда выносить общие сущности, типа дто, чтобы не дублировать код? Делать библиотеку на artifactory своем? Ух…

Ну и это я так, набросил просто парочку. В общем все сразу усложняется, и вы начинаете заниматься не фичами, а именно микросервисами сначала.

Я бы сказал, что к микросервисам стоит переходить как-то эволюционно. В какой-то момент монолит начинает показывать себя плохо, и тогда нужно садиться и думать, как переехать на микросервисный подход. И это прям задача, требующая размышлений и черновой работы.

Вы удивитесь, возможно, но в BigTech монолит – это крайне часто используемый формат. Т.е. микросервисы не везде. И вообще есть эпизоды эволюции вашей системы, когда микросервисы начинают работать плохо, и вам нужно искать другие решения.

Например, вы, вероятно, слышали про Amazon Prime Video. Ну там сериальчики можно посмотреть, все дела. Так вот они недавно имели архитектуру, которая работала на AWS Lambda и была разбита на атомарные компоненты. В какой-то момент они подумали и решили: “А давай-ка на монолит все перетащим”.

Результат: они урезали стоимость работы сервиса на 90% благодаря этому. Просто представьте, что вы каждый месяц тратите миллионы долларов на это. А тут бац – и в 10 раз меньше!

Посмотреть поподробнее про это можно здесь, например. Очень хороший канал, кстати, рекомендую. Таких мало. Его сделали авторы книжки “System Design Interview”, по которой можно готовиться к собесам, разумеется.

Короче, не торопитесь рисовать микросервисы. Лучше стартаните с одного проекта и заставьте его работать. А потом, если захотите потренироваться, упражняйтесь в разбиении на микросервисы.
  • 👍 7
More from @itarchitecture
  1. Jul 17, 2026https://www.youtube.com/live/N_n3AQtrfEU?si=h3IaD4Avi-LFgGMi
  2. Apr 16, 2026Technology Radar за апрель 2026 Почитал свежий Technology Radar. Если коротко: мы входим в…
  3. Mar 5, 2026Dual Write Problem Dual Write Problem (проблема двойной записи) возникает, когда две или б…
  4. Feb 6, 2026День из жизни Solutions Architect #fun
  5. Jan 17, 2026Как внедряли DDD в Яндекс360 - Что такое DDD и зачем он нужен? - Какой книгой лучше всего…
  6. Jan 9, 2026🎬 Архитектура предпросмотра видео в Netflix Когда вы наводите курсор на таймлайн Netflix,…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →