> Какие технологии и стеки вам интересны (Go)

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

Мне интересны стеки, где Go используется как ядро высоконагруженных распределённых систем: микросервисы на gRPC, event-driven архитектура с Kafka/NATS, работа с PostgreSQL и Redis. Привлекают технологии, решающие проблемы масштабирования и отказоустойчивости: Kubernetes, Prometheus, Grafana, Jaeger. Также интересны смежные языки для инфраструктурных задач - Python для скриптов автоматизации и TypeScript для внутренних инструментов. Главный критерий - зрелость экосистемы и возможность писать чистый, тестируемый код.

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

Мой интерес к стеку определяется не модой, а практическими задачами, которые приходится решать backend-разработчику уровня senior. В Go-экосистеме я выделяю несколько ключевых направлений:

1. Коммуникация между сервисами - gRPC как основной протокол для внутренних вызовов (protobuf-контракты, streaming, deadline propagation) и REST/GraphQL для внешнего API. Плюс message broker для асинхронных сценариев: Kafka для высокого throughput, NATS JetStream для более простых задач.

2. Хранение данных - PostgreSQL как основная реляционная БД (с паттернами partitioning, connection pooling через PgBouncer), Redis для кэширования и rate limiting, ClickHouse для аналитических запросов.

3. Инфраструктура - Kubernetes как стандарт оркестрации, Docker для изоляции, Helm для управления чартами. Обязательно observability: Prometheus + Grafana для метрик, OpenTelemetry для трейсинга, Loki для логов.

4. Инструменты разработки - Makefile для автоматизации, golangci-lint для статического анализа, testify для тестов, mockgen для генерации моков.

5. Смежные технологии - Envoy как service mesh sidecar, Terraform для IaC, GitHub Actions или GitLab CI для пайплайнов.

Мне интересны стеки, где есть явный trade-off между простотой и функциональностью. Например, выбор между синхронным gRPC и асинхронным Kafka - это всегда компромисс между latency и надёжностью доставки. Именно такие решения - где нужно думать, а не просто копировать шаблон - мне наиболее интересны.

На практике

В реальных проектах я предпочитаю следующий набор:

• Язык: Go 1.22+ с использованием generics, context, error wrapping
• Фреймворки: chi или echo для HTTP, google.golang.org/grpc для RPC
• БД: PostgreSQL + pgx driver, Redis через go-redis
• Брокеры: Kafka через segmentio/kafka-go или franz-go
• Конфигурация: envconfig или viper
• Логирование: slog (стандартный) или zap для структурированных логов
• Тестирование: testcontainers-go для интеграционных тестов, gofakeit для генерации данных

Например, в последнем проекте мы строили платёжный шлюз: Go-сервисы общались через gRPC, события о транзакциях уходили в Kafka, состояние хранилось в PostgreSQL с оптимистичной блокировкой. Для идемпотентности использовали Redis с TTL. Нагрузка - около 5k RPS на инстанс, горизонтальное масштабирование через K8s HPA по CPU и latency.

Пример кода

Показательный фрагмент - обработка входящего gRPC-запроса с идемпотентностью и публикацией события:

GO
func (s *PaymentService) CreatePayment(ctx context.Context, req *pb.CreatePaymentRequest) (*pb.CreatePaymentResponse, error) {
    // идемпотентность через Redis
    idempotencyKey := req.GetIdempotencyKey()
    if cached, err := s.redis.Get(ctx, "idem:"+idempotencyKey).Result(); err == nil {
        var resp pb.CreatePaymentResponse
        json.Unmarshal([]byte(cached), &resp)
        return &resp, nil
    }

    // бизнес-логика с транзакцией
    paymentID, err := s.store.CreatePayment(ctx, req)
    if err != nil {
        return nil, status.Errorf(codes.Internal, "create payment: %v", err)
    }

    // публикация события
    event := PaymentCreatedEvent{PaymentID: paymentID, Amount: req.GetAmount()}
    if err := s.kafka.Publish(ctx, "payments.created", event); err != nil {
        s.logger.Error("publish event", "error", err)
        // не возвращаем ошибку - событие будет доставлено outbox-паттерном
    }

    resp := &pb.CreatePaymentResponse{PaymentId: paymentID}
    // кэшируем ответ для идемпотентности
    data, _ := json.Marshal(resp)
    s.redis.Set(ctx, "idem:"+idempotencyKey, data, 24*time.Hour)

    return resp, nil
}

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

1. Структурируйте ответ: начните с ядра (Go + микросервисы), затем переходите к смежным технологиям. Не перечисляйте всё подряд - выделите 3-4 ключевых направления.

2. Привязывайте к опыту: каждый упомянутый инструмент должен иметь конкретный пример использования. Фраза "использовал Kafka" слабее, чем "настраивал consumer group с ручным управлением offset для гарантии exactly-once".

3. Покажите осознанность trade-off: например, "выбрали NATS вместо Kafka, потому что нам не нужна репликация через Zookeeper, а throughput 100k msg/s достаточно".

4. Упомяните, что готовы учиться новому: "сейчас присматриваюсь к Dapr для упрощения распределённых паттернов, но пока не использовал в production".

5. Не критикуйте стек компании: если интервьюер упомянул технологии, которые вам не нравятся, скажите "не работал с этим в production, но понимаю, зачем это используется".

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

• Глубину понимания экосистемы: знаете ли вы не только названия, но и внутреннее устройство (например, как работает gRPC поверх HTTP/2, чем отличается Kafka от RabbitMQ).
• Практический опыт: умеете ли вы обосновать выбор технологии под конкретную задачу, а не просто перечисляете buzzwords.
• Широту кругозора: интересуетесь ли вы только Go или понимаете, как ваш сервис вписывается в общую архитектуру (K8s, observability, CI/CD).
• Способность к обучению: готовы ли вы осваивать новые инструменты или застряли в одном стеке.
• Уровень seniority: senior должен не просто использовать инструменты, а понимать их ограничения и альтернативы.

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

• Перечисление без контекста: "знаю Go, Docker, K8s, Kafka, Redis" - это не ответ, а список из вакансии. Нужно объяснить, зачем и как вы их использовали.
• Излишняя экзотика: упоминание niche-технологий без production-опыта выглядит подозрительно. Лучше честно сказать "изучаю, но не использовал".
• Критика без альтернативы: "ненавижу PHP" или "Kubernetes слишком сложный" - показывает незрелость. Вместо этого: "предпочитаю serverless для простых задач, но понимаю, что K8s нужен для stateful-сервисов".
• Игнорирование вопроса: если спросили про интересные стеки, не нужно рассказывать про весь свой опыт. Сфокусируйтесь на том, что вам действительно нравится.
• Отсутствие конкретики: "мне нравится Go" - слишком общо. Добавьте: "нравится за простоту конкурентности через goroutines и встроенный профилировщик pprof".