Расскажи про последнее место работы

Мое последнее место работы (2021-2024 гг.)

Мое последнее место работы — это позиция Senior Go Developer / Tech Lead в крупной финтех-компании (аналогичной Тинькофф, Альфа-Банку), где я работал над высоконагруженным микросервисным ядром для системы онлайн-платежей и кредитного скоринга в реальном времени. Компания работала по модели B2B2C, предоставляя white-label решения для партнеров (маркетплейсы, сервисы доставки).

Ключевые проекты и зона ответственности

• Разработка и поддержка ядра платежного шлюза. Мой основной проект — это высоконагруженный REST/gRPC API-шлюз на Go, который обрабатывал до 50,000 транзакций в минуту в пиковые нагрузки (например, Black Friday).
• Архитектура и система. Мы использовали чистую микросервисную архитектуру (12+ сервисов на Go). Моя команда (5 разработчиков) отвечала за 4 ключевых сервиса:

    *   `transaction-orchestrator` — оркестратор бизнес-логики платежа.
    *   `fraud-detection-api` — интеграция с ML-моделями для анализа рисков.
    *   `ledger-service` — сервис учета финансовых проводок (двойная бухгалтерия).
    *   `reconciliation-engine` — движок автоматической сверки с банками-эквайерами.

• Технический стек: Язык — Go 1.19 → 1.21. Основные фреймворки и библиотеки: chi (роутинг), gRPC (внутренняя коммуникация), entgo (ORM), pgx (драйвер PostgreSQL). Базы данных: PostgreSQL (основная, с паттерном CQRS), Redis (кеш и distributed locks), Apache Kafka (асинхронные события). Инфраструктура: Kubernetes, Docker, GitLab CI/CD, мониторинг через Prometheus + Grafana и трассировка Jaeger.

Мои ключевые достижения и вклад

1. Рефакторинг и оптимизация производительности. Переписал критический путь авторизации платежа, что снизило p99 latency с 450ms до 120ms. Достигнуто за счет:

    *   Устранения N+1 запросов через **предзагрузку (eager loading)** в `entgo`.
    *   Введения двухуровневого кеширования (**in-memory LRU-кеш** + **Redis**).
    *   Оптимизации пула соединений с БД и настройки `sync.Pool` для часто аллоцируемых структур.

```go
// Пример: оптимизация кеширования данных мерчанта
type MerchantCache struct {
    sync.RWMutex
    local  *lru.Cache
    redisClient *redis.Client
}

func (c *MerchantCache) Get(ctx context.Context, id string) (*Merchant, error) {
    // 1. Проверка локального LRU-кеша
    c.RLock()
    if val, ok := c.local.Get(id); ok {
        c.RUnlock()
        return val.(*Merchant), nil
    }
    c.RUnlock()

    // 2. Проверка Redis
    data, err := c.redisClient.Get(ctx, "merchant:"+id).Bytes()
    if err == nil {
        merchant := &Merchant{}
        if json.Unmarshal(data, merchant) == nil {
            c.Lock()
            c.local.Add(id, merchant)
            c.Unlock()
            return merchant, nil
        }
    }

    // 3. Fallback to DB
    merchant, err := fetchFromDB(ctx, id)
    if err != nil {
        return nil, err
    }
    // Обновляем оба уровня кеша асинхронно
    go c.updateCaches(id, merchant)
    return merchant, nil
}
```

2. Внедрение отказоустойчивости. Разработал и внедрил паттерны Circuit Breaker (используя sony/gobreaker) и Retry with Exponential Backoff для всех внешних вызовов к банковским API. Это повысило устойчивость системы и снизило количество failed-транзакций из-за временной недоступности партнеров на ~30%.

1. Лидерство и менторство. Как техлид, я проводил code-review, занимался планированием спринтов, а также активно участвовал в онбординге новых разработчиков. Внедрил практику парного программирования для сложных задач и написал 3 внутренние библиотеки (для логгирования, валидации конфигов и работы с Kafka), что стандартизировало код и ускорило разработку.

Почему я ушел и что вынес из этого опыта

Я покинул компанию, так как искал новый вызов — возможность строить систему с нуля или углубиться в архитектурные решения еще более высокого масштаба (например, в сфере high-frequency trading или глобальных платформ).

Главные профессиональные выводы:

• Важность observability: В распределенных системах без детального мониторинга (метрики, логи, трейсы) работа вслепую невозможна.
• Компромиссы в распределенных транзакциях: Мы отказались от распределенных транзакций (2PC) в пользу Saga-паттерна с компенсирующими действиями через Kafka, что было правильным решением для нашей предметной области.
• Код как актив: Качество кода и продуманная архитектура напрямую влияют на скорость развития бизнеса. Инвестиции в тесты (у нас было ~85% coverage), чистую архитектуру и документирование окупаются многократно.

Этот опыт закалил меня как специалиста, способного не только писать эффективный и идиоматичный код на Go, но и проектировать, развертывать и поддерживать критически важные для бизнеса системы, которые работают 24/7 и обрабатывают миллионы операций ежедневно.