> Расскажи про последнее место работы, задачи и архитектуру (Go)

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

Последнее место - backend-разработка на Go в сервисе доставки. Отвечал за API-слой, интеграции с внешними системами и фоновые обработчики. Архитектура - монолит с чётким разделением на модули, PostgreSQL как основная БД, Redis для кэша и очередей, Kafka для событий. Основная задача - поддержка и развитие функциональности заказов, включая расчёт стоимости, статусы и интеграцию с партнёрами.

Подробное объяснение

Сервис обрабатывал заказы: создание, изменение, отмену, расчёт доставки. Монолит на Go, разбит на модули по доменным областям: заказы, доставка, платежи, пользователи. Каждый модуль имел свой слой handler → service → repository. HTTP-запросы обрабатывались через net/http с собственным middleware для логирования, auth и recovery. Фоновая логика - worker'ы на Kafka consumer group, которые обрабатывали события типа order_created, payment_confirmed.

Основные компоненты:

• API Gateway (nginx) → Go-сервис
• PostgreSQL - основное хранилище, миграции через golang-migrate
• Redis - кэш справочников и rate limiting
• Kafka - событийная шина для внутренних и внешних интеграций
• Prometheus + Grafana - метрики, Jaeger - трейсинг

Моя зона ответственности - модуль заказов и интеграция с партнёрскими API доставки. Типичная задача: добавить новый статус заказа, который выставляется после подтверждения курьером. Это затрагивало модель данных, обработчик события, обновление API-ответа и тесты.

На практике

В работе использовал стандартный подход: handler принимает запрос, валидирует, вызывает service, который содержит бизнес-логику и работает с repository. Транзакции - только на уровне repository, чтобы избежать вложенных транзакций. Для внешних вызовов - retry с exponential backoff и circuit breaker через go-resiliency.

Пример реальной задачи: нужно было добавить поддержку промокодов в расчёт стоимости. Реализация:

• новая таблица promocodes и связь с заказом
• сервисный метод CalculatePrice принимает промокод, проверяет его в Redis (кэш), при отсутствии - запрос в БД
• событие promocode_applied отправляется в Kafka для аудита

Тесты - unit на service с mock repository, интеграционные на handler с testcontainers (PostgreSQL). Покрытие ключевых сценариев - около 80%.

Пример кода

GO
type OrderService struct {
    repo   OrderRepository
    cache  *redis.Client
    kafka  KafkaProducer
}

func (s *OrderService) CalculatePrice(ctx context.Context, orderID string, promo string) (int, error) {
    order, err := s.repo.GetByID(ctx, orderID)
    if err != nil {
        return 0, fmt.Errorf("get order: %w", err)
    }

    discount := 0
    if promo != "" {
        discount, err = s.getPromoDiscount(ctx, promo)
        if err != nil {
            return 0, fmt.Errorf("get promo discount: %w", err)
        }
    }

    price := order.BasePrice - discount
    if price < 0 {
        price = 0
    }

    if err := s.kafka.Publish(ctx, "promocode_applied", map[string]string{
        "order_id": orderID,
        "promo":    promo,
    }); err != nil {
        // не фатально, логируем
    }

    return price, nil
}

func (s *OrderService) getPromoDiscount(ctx context.Context, promo string) (int, error) {
    if val, err := s.cache.Get(ctx, "promo:"+promo).Int(); err == nil {
        return val, nil
    }
    // fallback в БД
    return s.repo.GetPromoDiscount(ctx, promo)
}

Как отвечать на собеседовании

Структурируй ответ: сначала общий контекст (что за сервис, какая роль), потом архитектура (компоненты, связи), затем конкретные задачи и твой вклад. Упоминай trade-off: почему монолит, а не микросервисы - для этого масштаба и команды это было оправдано. Покажи, что понимаешь, как твой код влияет на систему в целом: например, добавление статуса заказа затрагивает не только БД, но и события, API-контракт, тесты.

Если спрашивают про конкретную архитектуру - не уходи в детали реализации, сначала опиши схему, потом пример. Используй термины: domain layer, repository pattern, event-driven, idempotency. Подчеркни, что умеешь работать с распределёнными системами: Kafka, retry, dead letter queue.

Что проверяет интервьюер

• Умение структурированно описать систему, а не перечислять технологии
• Понимание слоёв и ответственности: handler, service, repository
• Знание паттернов: repository, middleware, event-driven
• Практический опыт с Go: работа с ошибками, контекстом, конкурентностью
• Умение обосновать архитектурные решения: почему монолит, почему Kafka, а не RabbitMQ
• Насколько глубоко ты понимаешь жизненный цикл запроса и данных

Типичные ошибки

• Перечисление технологий без связи с задачами: "использовал Go, PostgreSQL, Redis" - без объяснения зачем
• Слишком высокоуровневый ответ: "делал микросервисы" - без деталей, что именно делал
• Уход в нерелевантные детали: расписывать настройку nginx, когда спрашивают про бизнес-логику
• Не упоминать про тесты, ошибки, мониторинг - это показывает незрелость
• Путаница в терминах: называть handler "контроллером", или путать event-driven с message queue
• Не упоминать trade-off: если всё идеально - это подозрительно, интервьюер ждёт, что ты знаешь ограничения своего решения