Вернуться в каталог собеседований

Виталий Лихачев, Олег Козырев : Публичное собеседование Senior Golang Developer

Публичное мок-собеседование Senior Golang-разработчика с практической задачей о кэшировании и защите платного внешнего API в микросервисной системе. Разговор переходит от проектирования и псевдокода к масштабированию, мониторингу и вопросам из чата.

{ между скобок }
  • Опубликовано на YouTube:
  • Просмотры на YouTube: 8,7 тыс.
  • Лайки на YouTube: 194
Открыть на YouTube

Таймлайн

Коротко о видео

Это публичное мок-собеседование по Go для уровня Senior, в котором участник проектирует сервис-кэш перед платным и нестабильным внешним API. Обсуждаются cache hit/miss, дедупликация параллельных запросов по одному ключу, горутины и каналы, масштабирование на несколько реплик через Redis, лимиты и наблюдаемость. В конце интервьюер даёт обратную связь по system design, после чего участники отвечают на вопросы о развитии, микросервисах, work-life balance и материалах по Go.

Затронутые темы

Что взять на заметку

  • Для платного внешнего API недостаточно просто добавить кэш: путь cache hit должен возвращать данные без нового обращения во внешний сервис.
  • При cache miss нужно дедуплицировать одновременные запросы по одному идентификатору: один запрос получает данные, а ожидающие получают тот же результат или ошибку.
  • Один обычный канал не выполняет широковещательную доставку результата нескольким горутинам; обсуждался вариант хранить для ключа список каналов ожидающих запросов.
  • При работе в нескольких репликах раздельные Redis GET и SET создают race condition; для захвата блокировки нужна атомарная операция, например SET с флагом NX.
  • Для сервиса нужны метрики эффективности кэша, нагрузки и задержек внешнего API, числа горутин, CPU/памяти, RPS по внутренним клиентам, а также логи и трассировка.
  • При избытке ожидающих запросов лучше ограничивать параллельное ожидание и отвечать HTTP 429 с указанием, когда повторить запрос, чем удерживать множество соединений.
  • На system design-собеседовании важно уточнять число реплик и ограничения системы: решение для одного инстанса не переносится автоматически на распределённый сценарий.

Рекомендуем посмотреть