Перейти к основному содержимому

Собеседование по Golang с CTO из американского FinTech. Почему опыт в бигтехе может помешать?

· 22 мин. чтения
ШОРТКАТ: Golang — менторская программа
ШОРТКАТ: Golang — менторская программа

Сегодня мы разберем типичное собеседование на позицию Go-разработчика, где фокус сместился с сухого заучивания структур данных на реальную production-проблематику: кандидату предстоит провести аудит сервиса по приему платежей, найти слабые места в архитектуре, обработке ошибок и безопасности, а затем вместе с интервьюером обсудить, как привести код к промышленным стандартам.

Вопрос 1. Какие нагрузки ожидаются на сервис и в чем проблема текущего подхода к разработке?​

Таймкод: 00:05:23

Ответ собеседника: Правильный. Сервис будет работать с нагрузкой до нескольких тысяч RPS. Код написан на коленке, но должен будет выдерживать значительные нагрузки в будущем, что создает риски масштабируемости и надежности.

Правильный ответ:

Сервис рассчитан на несколько тысяч RPS (requests per second), что соответствует десяткам миллионов запросов в сутки. На таких объемах архитектурные и кодовые компромиссы, приемлемые для MVP или прототипа, превращаются в системные риски.

1. Проблема текущего подхода

Код, написанный “на коленке”, обычно характеризуется:

  • жесткой связанностью компонентов (tight coupling),
  • отсутствием четких границ контекстов и слоев,
  • минимальной или непродуманной обработкой ошибок и таймаутов,
  • синхронной обработкой запросов без учета backpressure,
  • отсутствием наблюдаемости (структурированного логирования, метрик, трейсирования),
  • неявными зависимостями от внешних ресурсов (БД, сторонние API).

При росте RPS эти свойства приводят к:

  • лавинообразному росту задержек (latency tail amplification) из-за head-of-line blocking,
  • неустойчивости к всплескам трафика (cascading failures),
  • сложности горизонтального масштабирования из-за stateful-компонентов внутри обработчиков,
  • непредсказуемому поведению при частичных сбоях внешних зависимостей.

2. Архитектурные требования под нагрузку

Для стабильной работы на нескольких тысячах RPS требуется:

  • Пулы соединений и ограничение конкурентности
    Для внешних зависимостей (БД, HTTP-клиенты) должны быть настроены ограничения:

    • MaxOpenConns, MaxIdleConns, ConnMaxLifetime для sql.DB,
    • ограничения на общее количество одновременных запросов (например, через semaphore.Weighted или golang.org/x/sync/semaphore).

    Пример настройки пула БД:

    db, err := sql.Open("postgres", dsn)
    if err != nil {
        return err
    }
    db.SetMaxOpenConns(100)
    db.SetMaxIdleConns(50)
    db.SetConnMaxLifetime(5 * time.Minute)

  • Context propagation и таймауты на всех уровнях
    Каждый входящий запрос должен иметь deadline, который распространяется на все downstream-вызовы:

    ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
    defer cancel()

    result, err := service.Process(ctx, req)
    if errors.Is(ctx.Err(), context.DeadlineExceeded) {
        return ErrTimeout
    }

  • Circuit breaker и retry с jitter
    Для защиты от каскадных сбоев при частичных падениях внешних сервисов:

    cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
        Name: "external-api",
        MaxRequests: 5,
        Interval: 10 * time.Second,
        Timeout: 30 * time.Second,
        ReadyToTrip: func(counts gobreaker.Counts) bool {
            return counts.ConsecutiveFailures > 10
        },
    })

  • Наблюдаемость как базовое свойство
    Структурированные логи, метрики (RPS, latency p50/p95/p99, error rate) и distributed tracing (OpenTelemetry) — не “опция для продакшена”, а основа для обнаружения и локализации проблем.

  • Статeless дизайн и горизонтальное масштабирование
    Обработчики должны быть безсостоянечными. Вся сессия или состояние — во внешних хранилищах (Redis, БД). Это позволяет масштабировать сервис линейно за счет добавления инстансов за балансировщиком.

3. Эволюция кода от MVP к production-рейди

Переход от “написано на коленке” к устойчивой системе должен включать:

  • выделение явных доменных границ и интерфейсов (dependency inversion),

  • внедрение DI-контейнера или фабрик для управления жизненным циклом компонентов,

  • декомпозицию монолитных обработчиков на middleware-цепочки и слои (transport, usecase, repository),

  • контрактное тестирование внешних зависимостей (например, Pact),

  • нагрузочное тестирование с инструментами вроде vegeta или k6 для выявления узких мест до выхода в production:

    echo "GET http://localhost:8080/api/v1/resource" | vegeta attack -rate=5000 -duration=30s | vegeta report

4. Риски без рефакторинга

Без изменения подхода при росте RPS можно ожидать:

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

Резюмируя: текущий подход приемлем для валидации идеи, но противоречит требованиям к надежности и масштабируемости при нескольких тысячах RPS. Переход к production-рейди системе требует выведения надежности, наблюдаемости и контрактности в первый класс архитектурных требований, а не оставления их на “потом”.

Вопрос 2. Почему использование указателя на time.Time для работы с базой данных является плохой практикой?​

Таймкод: 00:20:06

Ответ собеседника: Правильный. Использование указателя на time.Time может привести к панике при обращении к nil-указателю, если разработчик забудет проверку наличия. В Go есть специальный тип sql.NullTime, который безопаснее и удобнее для работы со значениями NULL из базы данных.

Правильный ответ:

Использование *time.Time для маппинга nullable-значений из базы данных — это антипаттерн в Go по нескольким причинам: семантической, эргономической и связанной с управлением состоянием.

1. Семантика и нулевые значения

В Go нулевое значение — это базовая особенность языка. Для time.Time нулевым значением является 0001-01-01 00:00:00 +0000 UTC, что не является валидным календарным значением. Это позволяет отличать “поле не заполнено” от “поле явно пустое” без использования указателей.

Однако в реляционных базах данных NULL означает “значение отсутствует или неизвестно”, и этот смысл должен быть явно зафиксирован в доменной модели. Использование *time.Time смешивает два уровня:

  • технический (наличие указателя),
  • предметный (отсутствие значения).

Из-за этого возникает неопределенность: nil может означать как “не прочитали”, так и “не проинициализировали”, и компилятор не поможет это разделить.

2. Риск паник и утечек инвариантов

При работе с указателями каждое разыменование требует проверки. В бизнес-логике такие проверки часто дублируются или забываются:

if user.DeletedAt != nil && user.DeletedAt.After(now) {
    // потенциальная паника, если кто-то позже уберет одно из условий
}

Если указатель nil, любая операция *user.DeletedAt приведет к панике. Тип sql.NullTime инкапсулирует проверку внутри себя и гарантирует, что Valid отражает реальное состояние значения:

type NullTime struct {
    Time  time.Time
    Valid bool // Valid is true if Time is not NULL
}

3. Проблемы сериализации и ORM

Многие ORM и библиотеки для маппинга (например, sqlx, gorm, pgx) поддерживают sql.NullTime из коробки. При использовании *time.Time требуются дополнительные адаптеры или кастомные Scanner/Valuer, что увеличивает сложность кодовой базы и вероятность ошибок.

Пример корректной реализации интерфейсов для кастомного типа:

type NullTime time.Time

func (nt *NullTime) Scan(value interface{}) error {
    if value == nil {
        *nt = NullTime{}
        return nil
    }
    t, ok := value.(time.Time)
    if !ok {
        return fmt.Errorf("cannot scan type %T into NullTime", value)
    }
    *nt = NullTime(t)
    return nil
}

func (nt NullTime) Value() (driver.Value, error) {
    t := time.Time(nt)
    if t.IsZero() {
        return nil, nil
    }
    return t, nil
}

Но в стандартной библиотеке уже есть sql.NullTime, и его использование предпочтительнее.

4. Эволюция подходов: database/sql и sql.NullTime

Тип sql.NullTime решает проблему нулевых значений явно:

var deletedAt sql.NullTime
err := db.QueryRow("SELECT deleted_at FROM users WHERE id = $1", id).Scan(&deletedAt)
if err != nil {
    return err
}
if deletedAt.Valid {
    // значение есть в БД, даже если это "нулевая" дата
    fmt.Println("deleted at:", deletedAt.Time)
} else {
    // NULL в БД
    fmt.Println("not deleted")
}

Это устраняет необходимость в ручных проверках указателей и делает состояние частью типа.

5. Современные альтернативы

В новых проектах часто используют обертки с поддержкой JSON и удобным API:

type NullTime struct {
    time.Time
    Valid bool
}

func (nt NullTime) MarshalJSON() ([]byte, error) {
    if !nt.Valid {
        return []byte("null"), nil
    }
    return nt.Time.MarshalJSON()
}

func (nt *NullTime) UnmarshalJSON(data []byte) error {
    // аналогичная логика для JSON
}

Либо переходят на использование pgtype в случае с PostgreSQL, где типы из pgtype предоставляют богатый набор семантически корректных нулевых значений.

6. Почему *time.Time все еще встречается

Иногда указатели оправданы, если NULL в БД нужно отличать от “поле не выбрано в запросе” (например, при частичном обновлении). Но даже в таких случаях лучше использовать:

  • отдельные DTO с указателями на уровне транспорта,
  • четкое разделение слоев, чтобы доменная модель оперировала sql.NullTime или time.Time, а не сырыми указателями.

Резюме

*time.Time для работы с БД — плохая практика, потому что:

  • он скрывает семантику отсутствия значения за техническим свойством указателя,
  • требует ручных проверок и подвергает код риску паник,
  • дублирует функциональность, уже предоставляемую sql.NullTime,
  • усложняет сериализацию и маппинг.

Использование sql.NullTime (или аналогичных типов с явным флагом Valid) делает код более надежным, выразительным и безопасным, особенно при росте сложности доменной модели и нагрузки на сервис.

Вопрос 3. Какие проблемы есть в текущем подходе к обработке ошибок и валидации?​

Таймкод: 00:30:07

Ответ собеседника: Правильный. Ошибки не централизованы, их сложно тестировать и локализовать. Предлагается вынести ошибки в отдельное место. Также валидация на уровне HTTP может избыточно дублировать текстовые сообщения, так как код ошибки уже достаточно для понимания проблемы.

Правильный ответ:

Текущий подход демонстрирует классические проблемы, возникающие при смешивании уровней ответственности и отсутствии единой стратегии работы с ошибками.

1. Отсутствие централизации и слоистости

Когда ошибки создаются непосредственно в обработчиках или бизнес-логике через errors.New или fmt.Errorf без типизации, это приводит к:

  • утечке деталей реализации: внутренние коды и тексты ошибок протекают на уровень API;
  • непроверяемости (untestability): сравнивать строки в тестах — плохая практика, так как они нестабильны при i18n или рефакторинге;
  • сложности локализации: отсутствие контекста (error code, domain, layer) делает невозможным адекватное логирование и метрики.

Решение — введение доменных типов ошибок и пакета, централизующего их объявления:

// domain/errors.go
package domain

import "fmt"

type Error struct {
    Code    string
    Message string
    Op      string
    Err     error
}

func (e *Error) Error() string {
    if e == nil {
        return ""
    }
    return fmt.Sprintf("%s: %s", e.Code, e.Message)
}

func (e *Error) Unwrap() error { return e.Err }

var (
    ErrNotFound        = &Error{Code: "NOT_FOUND", Message: "resource not found"}
    ErrInvalidArgument = &Error{Code: "INVALID_ARGUMENT", Message: "invalid argument"}
    ErrInternal        = &Error{Code: "INTERNAL", Message: "internal error"}
)

Это позволяет тестировать семантику, а не строки:

if !errors.Is(err, domain.ErrNotFound) {
    t.Fatal("expected not found")
}

2. Нарушение границ через валидацию на уровне HTTP

Валидация на транспортном уровне часто избыточна, если:

  • она дублирует семантические проверки, которые должны выполняться в домене;
  • генерирует текстовые сообщения, которые уже кодируются HTTP-статусами и структурированными телами ответов.

Проблема дублирования текста:

// ❌ антипаттерн
if user.Name == "" {
    http.Error(w, "name is required", http.StatusBadRequest)
    return
}

Здесь сообщение избыточно: код 400 и JSON с кодом ошибки достаточно для клиента. Текст лучше локализовывать на стороне клиента по error.code.

Правильный подход — fail-fast на границе, но с контрактными ошибками:

type Validator interface {
    Validate() error
}

func (u *User) Validate() error {
    if u.Name == "" {
        return domain.NewError("VALIDATION_ERROR", "name is required")
    }
    return nil
}

Транспортный слой обрабатывает только маршалинг и статусы:

if err := u.Validate(); err != nil {
    writeJSON(w, http.StatusBadRequest, map[string]interface{}{
        "error": err.(*domain.Error).Code,
    })
    return
}

3. Отсутствие контекста и трассировки

Ошибки без операционного контекста (Op, TraceID) невозможно эффективно искать в логах. Каждая ошибка должна включать метаданные:

&domain.Error{
    Code: "DB_TIMEOUT",
    Op:   "user.repository.GetByID",
    Err:  err,
}

Для распространения контекста и идентификаторов запросов используется context.Context и middleware:

func WithRequestID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        id := r.Header.Get("X-Request-ID")
        if id == "" {
            id = uuid.New().String()
        }
        ctx := context.WithValue(r.Context(), "requestID", id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

4. Стратегия обработки ошибок в pipeline

Вместо разрозненных проверок, ошибки должны обрабатываться конвейерно:

  • Транспорт: преобразование доменных ошибок в HTTP-статусы и тела.
  • Бизнес-слой: возврат типизированных ошибок.
  • Инфраструктура: обертка низкоуровневых ошибок (БД, сеть) в доменные коды.

Пример middleware для централизованной обработки:

func ErrorHandler(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {
                log.Printf("panic: %v", rec)
                writeJSON(w, http.StatusInternalServerError, map[string]string{
                    "error": "INTERNAL",
                })
            }
        }()

        next.ServeHTTP(w, r)
    })
}

5. Валидация как контракт, а не как текст

Современные подходы используют коды ошибок и структурированные ответы:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "field": "email",
    "message": "invalid format"
  }
}

Текстовое сообщение здесь вторично; первичен code. Это позволяет:

  • унифицировать обработку на клиенте,
  • исключить дублирование на разных языках в серверном коде,
  • упростить тестирование и документирование API.

6. Резюме

Проблемы текущего подхода:

  • отсутствие типизации и централизации ошибок,
  • смешение уровней ответственности (валидация и транспорт),
  • избыточность текстовых сообщений вместо кодов,
  • невозможность трассировки и адекватного логирования.

Путь к решению:

  • выделение доменного пакета ошибок,
  • использование кодов вместо строк,
  • валидация как контракт домена, а не как текстовый ответ транспорта,
  • middleware для централизации преобразования и логирования ошибок,
  • обязательное включение операционных метаданных в каждую ошибку.

Вопрос 4. Какие проблемы есть в подходе к генерации уникальных идентификаторов для транзакций?​

Таймкод: 00:41:25

Ответ собеседника: Правильный. Использование текущего времени (time.Now) для генерации уникальных ID транзакций небезопасно при высокой частоте запросов, так как возможны коллизии. Рекомендуется генерировать уникальные ID на уровне базы данных (например, автоинкремент или UUID в PostgreSQL) или использовать криптографически стойкие случайные значения, а не простое время.

Правильный ответ:

Использование time.Now (или производных от него значений) в качестве источника уникальности для идентификаторов транзакций в распределенных и высоконагруженных системах — это классическая архитектурная ошибка. Она компрометирует как корректность системы, так и ее масштабируемость.

1. Проблема разрешающей способности времени

Тип time.Time в Go имеет наносекундное разрешение, однако:

  • системные вызовы и планировщик могут квантовать выполнение горутин с точностью до микросекунд или миллисекунд;
  • виртуализация и контейнеризация (особенно под высокой нагрузкой) могут приводить к сдвигам и дублированию значений системных часов.

При RPS в несколько тысяч вероятность коллизии стремится к единице даже на одиночном узле:

// ❌ небезопасно
id := time.Now().UnixNano()

Если два события обрабатываются в одной горутине или попадают в один квант планировщика, UnixNano() вернет идентичные значения. Для идемпотентных систем и финансовых транзакций это означает потерю данных или дублирование операций.

2. Отсутствие пространственной уникальности

time.Now не содержит информации об источнике (узле, процессе, экземпляре). В распределенной топологии два независимых сервиса, генерирующие ID на основе локального времени, гарантированно произведут пересечение при любом масштабе.

Классические решения этой проблемы включают пространственные компоненты:

  • Snowflake-like ID (Twitter Snowflake, Sonyflake): timestamp + nodeID + sequence
  • ULID: timestamp (48 бит) + entropy (80 бит)
  • KSUID: timestamp + payload

Пример генерации ULID (без внешних зависимостей, через ulid):

import "github.com/oklog/ulid/v2"

id := ulid.Make()
// 01H8Z4Y8JZ1XK2J8G0T5R7W6Y5
// Сортируемый, содержит 48 бит времени + 80 бит энтропии

3. Проблемы с индексацией и вставкой в БД

Если идентификатор транзакции используется как первичный ключ (clustered index), монотонно возрастающие значения на основе времени вызывают page splits и hotspot-расщепление в B-деревьях (особенно в PostgreSQL и MySQL/InnoDB).

Это приводит к:

  • деградации вставки с ростом таблицы,
  • фрагментации страниц,
  • локам на уровне страниц при параллельных вставках.

Решения:

  • UUID v4 как первичный ключ (случайный, равномерное распределение), но с накладными расходами на хранение (16 байт) и фрагментацию индекса.
  • UUID v7 (новый стандарт, time-ordered): timestamp (48 бит) + rand (74 бит). Сочетает сортируемость и равномерность.

Пример схемы в PostgreSQL:

CREATE TABLE transactions (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- v4
    -- или для v7 (требуется extension/поддержка)
    id UUID DEFAULT uuid_generate_v7(),
    amount NUMERIC(18,2) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT now()
);

4. Идемпотентность и дедупликация

Генерация ID на клиенте или в обработчике без централизованной координации делает невозможной гарантированную идемпотентность. Если клиент повторит запрос из-за сетевой ошибки, новый time.Now создаст новый ID, и система воспримет это как новую транзакцию.

Правильный паттерн:

  • Идемпотентный ключ (idempotency key) передается от клиента (например, X-Idempotency-Key: uuidv4).
  • Сервер использует его для дедупликации через уникальный индекс или кэш (например, Redis с TTL).
  • Реальный ID транзакции генерируется системой (последовательность, ULID, KSUID).

5. Альтернативы и лучшие практики

A. База данных как источник уникальности

  • Последовательности (SERIAL, IDENTITY, SEQUENCE) гарантируют уникальность в пределах одной БД, но не масштабируются горизонтально без шардирования ключа.
  • Автоинкремент подходит для внутрисервисных сущностей, но не для распределенных транзакций.

B. Распределенные генераторы

  • Snowflake/sonyflake: требуют стабильного nodeID (через etcd, consul или конфигурацию).
  • ULID/KSUID: не требуют координации, сортируемы, URL-safe.

C. Гибридный подход

  • Для внешнего API использовать сортируемые, неугадываемые ID (ULID, UUID v7).
  • Для внутренней связи и индексации — bigint из последовательности или составной ключ (shard_id + local_id).

6. Резюме

Использование time.Now для ID транзакций небезопасно из-за:

  • вероятности коллизий при высокой частоте,
  • отсутствия пространственной уникальности,
  • проблем с индексацией (hotspot),
  • невозможности обеспечить идемпотентность.

Корректный подход:

  • использовать пространственно-временные идентификаторы (ULID, KSUID, UUID v7),
  • вынести генерацию в инфраструктурный слой (не в бизнес-логике),
  • применять idempotency keys для дедупликации запросов,
  • проектировать схему БД с учетом паттернов вставки (сортируемые ключи для снижения фрагментации).

Вопрос 5. Какие проблемы есть в реализации вебхука (webhook) для обработки событий от Stripe?​

Таймкод: 00:51:43

Ответ собеседника: Правильный. Отсутствует авторизация и проверка подписи (signature) вебхука, что позволяет любому отправить поддельное событие. Также в коде есть неэффективная утилизация процессора из-за частых и ненужных операций в цикле, например, избыточных проверок.

Правильный ответ:

Реализация вебхуков для платежных шлюзов — критически важный участок системы, поскольку именно через них проходит информация о финансовых событиях: подтверждения платежей, откатах, спорных ситуациях и фроде. Ошибки в этой части приводят к потере денег, нарушению консистентности данных и уязвимостям безопасности.

1. Отсутствие проверки подписи (Signature Verification)

Stripe передает заголовок Stripe-Signature для каждого вебхука. В нем содержится временная метка и криптографическая подпись, созданная с использованием секрета конечной точки (endpoint secret).

Без верификации любой может отправить HTTP-запрос с телом, имитирующим событие от Stripe, что приведет к:

  • фальшивым успешным платежам,
  • списаниям или активациям лицензий/доступов без фактического поступления средств,
  • возможному выполнению произвольного бизнес-кода (RCE через бизнес-логику).

Корректная проверка с использованием официального SDK:

import "github.com/stripe/stripe-go/v76/webhook"

const MaxBodyBytes = int64(65536)

func handleWebhook(w http.ResponseWriter, r *http.Request) {
    r.Body = http.MaxBytesReader(w, r.Body, MaxBodyBytes)
    payload, err := io.ReadAll(r.Body)
    if err != nil {
        http.Error(w, "Bad payload", http.StatusBadRequest)
        return
    }

    // stripeSignatureHeader извлекается из заголовка
    signature := r.Header.Get("Stripe-Signature")

    event, err := webhook.ConstructEvent(payload, signature, os.Getenv("STRIPE_WEBHOOK_SECRET"))
    if err != nil {
        http.Error(w, "Invalid signature", http.StatusUnauthorized)
        return
    }

    // Обработка event...
}

Важно:

  • ограничивать размер тела запроса (защита от DoS),
  • использовать константу секрета из переменных окружения,
  • не пытаться реализовать проверку подписи вручную (HMAC-SHA256) — лучше доверить SDK.

2. Уязвимость к атакам повторного воспроизведения (Replay Attacks)

Даже при наличии подписи, если не проверять временную метку (t в Stripe-Signature), злоумышленник может перехватить и повторно отправить старый вебхук.

SDK позволяет задать допустимое расхождение по времени (tolerance), чтобы защититься от этого:

event, err := webhook.ConstructEventWithOptions(payload, signature, os.Getenv("STRIPE_WEBHOOK_SECRET"), &webhook.ConstructEventOptions{
    Tolerance: 5 * time.Minute,
})

3. Недостаточная идемпотентность обработки

Сетевые ошибки могут приводить к повторной доставке одного и того же события (Stripe гарантирует доставку “at least once”). Если обработчик не идемпотентен, это приведет к двойным начислениям/списаниям или дублированию сущностей.

Решение — использовать идемпотентный ключ или проверять, обрабатывалось ли событие ранее:

// Используем ID события Stripe как уникальный ключ
if isAlreadyProcessed(event.ID) {
    w.WriteHeader(http.StatusOK)
    return
}

// Транзакционно: сохраняем событие и применяем изменения
err = db.InTransaction(func(tx *sql.Tx) error {
    if err := markEventProcessed(tx, event.ID); err != nil {
        return err
    }
    return applyBusinessLogic(tx, event)
})

4. Потеря событий при ошибках и отсутствие retry-логики

Если вебхук возвращает любой статус, отличный от 2xx, Stripe будет повторять доставку с экспоненциальной задержкой. Это может привести к:

  • “holes” в данных (дыры), если ошибка временная и не обрабатывается,
  • перегрузке системы из-за постоянных ретраев.

Правильный подход:

  • всегда возвращать 200 OK только после успешной обработки и сохранения состояния,
  • использовать очереди (например, NATS, RabbitMQ, SQS) для асинхронной обработки внутри сервиса, чтобы быстро освобождать HTTP-обработчик.
func handleWebhook(w http.ResponseWriter, r *http.Request) {
    // ... verify signature ...

    if err := eventQueue.Publish(r.Context(), event); err != nil {
        http.Error(w, "Internal error", http.StatusInternalServerError)
        return
    }

    w.WriteHeader(http.StatusOK)
}

5. Небезопасная работа с телом запроса и утилизация CPU

Частые ошибки при чтении r.Body:

  • отсутствие лимита на размер тела (риск исчерпания памяти),
  • многократное чтение тела (например, для логирования, а затем для верификации), что ломает Stripe-Signature, так как подпись считается от оригинального тела.

Корректно:

  • прочитать тело один раз в байтовый слайс,
  • использовать этот слайс и для верификации, и для парсинга,
  • ограничить размер через http.MaxBytesReader.

6. Игнорирование типа события и версионирования

Stripe может добавлять новые типы событий или менять структуру существующих. Если код использует прямое приведение типов без проверки event.Type, это может привести к паникам.

Лучшая практика — явная диспетчеризация:

switch event.Type {
case "payment_intent.succeeded":
    var intent stripe.PaymentIntent
    if err := json.Unmarshal(event.Data.Raw, &intent); err != nil {
        log.Printf("Failed to parse payment intent: %v", err)
        return
    }
    // handle
case "charge.refunded":
    // handle
default:
    // неизвестное событие — логируем, но не падаем
    log.Printf("Unhandled event type: %s", event.Type)
}

7. Нехватка наблюдаемости

Без трассировки и структурированных логов невозможно понять, почему вебхук не сработал или был обработан с ошибкой.

Необходимы:

  • логирование event.ID, event.Type, timestamp,
  • метрики: webhook_received_total, webhook_processing_duration_seconds, webhook_verification_failed_total,
  • интеграция с трейсингом (OpenTelemetry) для связывания вебхука с бизнес-операцией.

Резюме

Главные проблемы в реализации Stripe вебхука:

  • отсутствие проверки подписи (фатально для безопасности),
  • незащищенность от replay-атак,
  • неидемпотентная обработка,
  • синхронная и хрупкая бизнес-логика в HTTP-обработчике,
  • небезопасное чтение тела и утилизация ресурсов,
  • отсутствие наблюдаемости и обработки неизвестных событий.

Надежная реализация требует:

  • обязательной верификации через SDK,
  • строгой идемпотентности,
  • асинхронной обработки через брокер сообщений,
  • лимитов на размер тела и отказоустойчивой маршрутизации событий.

Вопрос 6. Какие проблемы есть в текущей реализации авторизации и валидации токена?​

Таймкод: 00:58:22

Ответ собеседника: Правильный. Токен передаётся в открытом виде (Base64), что небезопасно. Отсутствует надёжная проверка подписи и алгоритма шифрования. Дата истечения (exp) также передаётся открыто, что упрощает подделку. Нет проверки длины и структуры токена (parts). Используется небезопасный каст типов. В целом код переусложнён и содержит уязвимости, связанные с асимметричным шифрованием и подменой алгоритма (alg).

Правильный ответ:

Реализация авторизации на кастомных токенах или самописных JWT-парсерах часто страдает от смешения понятий “кодирование” и “шифрование”, отсутствия криптографических гарантий и избыточной сложности. Это приводит к классам уязвимостей, которые эксплуатируются тривиально.

1. Base64 — это не шифрование и не защита

Base64 — обратимое кодирование, цель которого представление бинарных данных в текстовом виде. Любой клиент может декодировать payload, изменить его и закодировать обратно.

Без криптографической подписи (HMAC) или асимметричного шифрования (RSA/ECDSA) токен не гарантирует:

  • целостности (Integrity),
  • аутентичности (Authenticity).

2. Уязвимость подмены алгоритма (Algorithm Confusion / alg: none)

Если валидатор на сервере поддерживает асимметричные алгоритмы (RS256), но при этом доверяет полю alg из токена, злоумышленник может:

  • сгенерировать токен с alg: HS256,
  • подписать его с помощью публичного ключа (который в RSA и HMAC — это просто число),
  • обойти проверку, если сервер использует публичный ключ как HMAC-секрет.

Корректная практика — жестко фиксировать ожидаемый алгоритм на стороне валидатора:

_, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
    // Защищаемся от подмены алгоритма
    if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
        return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
    }
    return publicKey, nil
})

Идеальнее — использовать библиотеки, которые алгоритм из токена игнорируют (например, github.com/golang-jwt/jwt/v5 с явной привязкой к ключу и алгоритму).

3. Отсутствие проверки структуры токена

До парсинга необходимо проверять базовые инварианты:

  • точное количество сегментов (для JWT это 3, разделенные точкой),
  • отсутствие пустых частей,
  • валидность Base64URL (без +, /, =).

Игнорирование этих проверок может приводить к паникам при индексации слайсов или strings.Split.

parts := strings.Split(token, ".")
if len(parts) != 3 {
    return ErrMalformedToken
}

4. Небезопасное приведение типов и отсутствие валидации полей

Использование map[string]interface{} без проверки наличия и типа полей (exp, iss, aud) ведет к:

  • паникам при приведении float64 (как в encoding/json) к int64,
  • игнорированию обязательных стандартных полей.

Вместо ручного каста следует использовать строго типизированные структуры или библиотеки с регистрацией Claims:

type CustomClaims struct {
    UserID string `json:"user_id"`
    jwt.RegisteredClaims
}

token, err := jwt.ParseWithClaims(tokenString, &CustomClaims{}, keyFunc)
if err != nil {
    return err
}

claims, ok := token.Claims.(*CustomClaims)
if !ok || !token.Valid {
    return ErrInvalidToken
}

// Теперь claims.ExpiresAt.Time — это time.Time, а не float64
if claims.ExpiresAt.Time.Before(now) {
    return ErrTokenExpired
}

5. Игнорирование exp, nbf, iat и aud

Даже если exp передается открыто, его необходимо проверять на сервере. Отсутствие проверки exp (времени истечения) делает токен вечным. Отсутствие nbf (not before) позволяет использовать “будущие” токены.

Кроме того, критично проверять:

  • iss (issuer) — ожидаемого эмитента,
  • aud (audience) — ожидаемого получателя, чтобы токен, выпущенный для другого сервиса, нельзя было использовать здесь.

6. Сложность и избыточность самописного кода

Часто самописные валидаторы пытаются реализовать:

  • ручной парсинг ASN.1 для RSA,
  • ручную проверку PEM-форматов,
  • ручную конвертацию base64url.

Это неизбежно ведет к ошибкам:

  • некорректной обработке паддинга,
  • игнорированию CRL/OCSP (отзыва сертификатов),
  • уязвимостям при сравнении подписей (timing attacks).

7. Timing-атаки при сравнении подписей

Если при проверке HMAC или сравнении хешей используется == на байтовых слайсах, это может привести к утечке информации через время ответа.

Всегда используйте константное время сравнения:

if !hmac.Equal(givenSig, expectedSig) {
    return ErrInvalidSignature
}

8. Отсутствие ротации ключей и жестких политик

Долгоживущие ключи без ротации увеличивают окно риска при их компрометации. Лучшие практики:

  • использование JWKS (JSON Web Key Set) для динамической выдачи ключей,
  • короткое время жизни токенов (минуты/часы),
  • обязательный refresh-токен для получения новых access-токенов.

Резюме

Текущая реализация содержит критические уязвимости:

  • Base64 вместо подписи,
  • доверие полю alg,
  • отсутствие проверки структуры и типов,
  • потенциальные паники и timing-уязвимости,
  • избыточная сложность вместо использования стандартных библиотек.

Путь исправления:

  • отказ от самописного парсера в пользу golang-jwt/jwt или аналогов,
  • жесткая привязка к алгоритму и проверка ключа,
  • обязательная валидация exp, nbf, iss, aud,
  • структурированные claims вместо map[string]interface{},
  • константное время сравнения и защита от алгоритмической подмены.

Вопрос 7. Что именно нужно сделать, чтобы получить бесплатное мок-интервью?​

Таймкод: 01:12:44

Ответ собеседника: Правильный. Нужно написать в поддержку платформы Shortcat или оставить заявку на мок-интервью через бота, указав, что вы выиграли бесплатное интервью в рамках акции.

Правильный ответ:

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

1. Инициация контакта с платформой

Вам нужно уведомить организаторов о готовности использовать выигранную возможность. Это можно сделать двумя равноценными способами:

  • Через службу поддержки: написать на email или в форму обратной связи на платформе Shortcat, указав тему или причину “Активация бесплатного мок-интервью (акция)”.
  • Через бота: оставить заявку в Telegram-боте или другом мессенджере, который интегрирован с сервисом, выбрав соответствующий сценарий или команду активации.

2. Указание контекста выигрыша

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

Примерный текст запроса: > “Здравствуйте. Я выиграл(а) бесплатное мок-интервью в рамках вашей недавней акции. Прошу активировать для меня доступ к тренировочному интервью на платформе Shortcat.”

3. Ожидание подтверждения и предоставления доступа

После отправки заявки:

  • модератор или бот проверят ваш профиль и статус участия в акции;
  • при подтверждении вам будет предоставлена ссылка на выбор или бронирование интервью (возможно, с выбором темы, уровня сложности или имитации конкретной компании);
  • вы сможете пройти интервью в выбранное время с обратной связью по результатам.

Резюме

Чтобы получить бесплатное мок-интервью, нужно:

  • связаться с поддержкой Shortcat или оставить заявку через бота;
  • сообщить, что вы выиграли интервью в рамках акции;
  • дождаться активации доступа и пройти интервью согласно инструкциям платформы.

Вопрос 8. Когда и на каком канале будут проходить следующие прямые эфиры?​

Таймкод: 01:14:15

Ответ собеседника: Правильный. Следующие прямые эфиры будут проходить каждый четверг в 19:00 на YouTube-канале.

Правильный ответ:

Следующие прямые эфиры запланированы на регулярной основе и пройдут каждый четверг в 19:00 по московскому времени. Трансляции будут вестись на официальном YouTube-канале.

Формат и регулярность:

  • Частота: еженедельно (по четвергам).
  • Время начала: 19:00 (UTC+3).
  • Платформа: YouTube (прямая трансляция в открытом доступе).

Рекомендации для участия:

  • Подписаться на канал и включить уведомления, чтобы не пропустить начало.
  • Заранее присоединяться к чату трансляции для задания вопросов в реальном времени.
  • Архивы эфиров будут доступны на канале сразу после завершения трансляции для повторного просмотра.