Питання Співбесіди про Мікросервіси

Ви прочитали назви патернів, можете продекламувати, що робить circuit breaker, і все одно не знаєте, що слухає комісія. Цей розділ називає чотири області, які оцінюють інтерв'юери, у порядку, в якому вони зазвичай їх досліджують. Кожна є питанням судження, перевдягненим у питання про словниковий запас.

• Декомпозиція. Де ви ріжете і чому саме там? Інтерв'юери хочуть межу, проведену вздовж бізнес-можливості або володіння даними, а не вздовж технічних шарів.
• Комунікація. Синхронний запит/відповідь чи асинхронні події, і що ламається в кожному випадку. Бажана відповідь це компроміс, а не перевага.
• Дані. Одна база даних на сервіс означає відсутність join між сервісами і відсутність розподіленої транзакції. Як ви все одно підтримуєте систему коректною?
• Операції. Розгортання, версіонування, трасування, і що відбувається о третій ночі, коли один сервіс повільний, а не впав.

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

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

• Як би ви розділили цей моноліт на сервіси? Перевіряє, чи ріжете ви вздовж бізнес-можливостей і володіння даними, чи вздовж шарів controller, service і repository. Друга відповідь дає розподілений моноліт.
• Як два сервіси спілкуються між собою? Перевіряє, чи можете ви назвати вартість кожного вибору: синхронні виклики дають просту ментальну модель, але зв'язують доступність, асинхронні події розв'язують доступність і дають eventual consistency, яку треба пояснити product owner.
• Що таке розподілений моноліт і як його уникнути? Перевіряє, чи знаєте ви, що сервіси, які мусять розгортатися разом, насправді не окремі.
• Яким великим має бути сервіс? Перевіряє, чи встоїте ви перед числом. Розмір слідує за межею і командою, яка нею володіє.
• Чи потрібен API gateway і що він робить? Перевіряє, чи можете ви відокремити routing, автентифікацію і rate limiting від бізнес-логіки.
• Як сервіси знаходять один одного? Перевіряє базове знайомство з service discovery і чому жорстко прописані host'и не спрацьовують у масштабованому середовищі.

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

Саме тут співбесіди вигравають чи програють, бо ці питання не мають чистої відповіді, і кандидати тягнуться до заученої напам'ять.

• Як ви підтримуєте узгодженість даних між сервісами? Спершу назвіть обмеження: міжсервісної транзакції не існує. Потім опишіть saga, яка або хореографується через події, або оркеструється координатором, і скажіть прямо, що система eventually consistent, і що бачить користувач у цьому проміжку.
• Що відбувається, коли downstream-сервіс повільний? Тайм-аути, повтори з backoff, і circuit breaker, щоб повільна залежність не вичерпала ваш thread pool. Повільність гірша за падіння, і сказати це показує виробничий досвід.
• Як зробити повтор безпечним? Idempotency. Ключ ідемпотентності на шляху запису, щоб повторений платіж списувався лише раз.
• Як обробити частковий збій у багатокроковому потоці? Компенсаційні дії, а не rollback. Поясніть, як виглядає повернення коштів або звільнення резервації.
• Як налагодити запит, що торкнувся шести сервісів? Distributed tracing з correlation ID, що поширюється через кожен hop, плюс структуровані логи і метрики.

Бекенд-інженер, що проходив співбесіду на роль platform L5 у публічного хмарного постачальника, отримав питання про saga і відповів за один прохід, словником патернів, жодного разу не згадавши, що побачив би клієнт. Уточнювальне питання, що показує сторінка замовлення в вікні неузгодженості, це те питання, яке насправді вирішує раунд. Готуйте другу відповідь, а не лише першу.

Більше банків питань за роллю і темою зібрано під питаннями співбесіди за роллю.

Читання цього списку дає відчуття впізнавання, і це відчуття зникає, щойно незнайомець ставить питання і чекає. Розрив між знанням патерну і поясненням його під легким тиском це вся складність раунду system design, і закривається він лише через говоріння.

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

Aaron Cao, засновник SubcueAI, побудував режим практики навколо цього розриву, а не навколо подачі контенту. Списки питань вільно доступні всюди; чого кандидатам бракує, це повторень промовляння відповіді, поки хтось чекає. Під час реальної співбесіди десктопний застосунок і Side Panel розширення браузера можуть показувати структуровані підказки, поки говорить інтерв'юер, хоча відрепетируване пояснення завжди переважає те, яке ви читаєте вперше. Що асистент робить і чого не робить, описано в огляді продукту.