😎 Топ-вакансий для Go-разработчиков за неделю

Senior Backend Engineer — от 600 000 ₽, удаленно (Москва)

Senior Go / Kubernetes Engineer — до 7 000 $, удаленка в Москве

Go Developer — до 400 000 ₽, удаленно (Москва)

Senior Golang Developer — от 400 000 ₽, удаленка в Москве

Golang-разработчик — от 3500 до 4000 $, удаленно (Москва)

Бустер — удалённо (не только Москва)

➡️ Еще больше топовых вакансий — в нашем канале Go jobs

🗑 Как действительно удалять чувствительные данные в системах с кэшем. Часть 1

Данные проходят через множество слоёв: браузер → CDN → балансировщик → брокер сообщений → сервисы → распределённый кэш → полнотекстовый поиск → БД (и её логи/кэши).

Чтобы «стереть» их, нужно инвалидировать и подчистить каждый слой.

1. Клиент: не кэшировать чувствительное

Отдавайте такие ответы с Cache-Control: no-store и без ETag/Last-Modified.

// middleware: запрет кэширования чувствительных ответов
func noStore(next http.Handler) http.Handler {
  return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Cache-Control", "no-store")
    w.Header().Del("ETag")
    w.Header().Del("Last-Modified")
    next.ServeHTTP(w, r)
  })
}

2. CDN: точечная инвалидация и короткие TTL

Для публичных данных — ETag/short TTL; для приватных — вообще не пускать в CDN (поддомен без CDN / приватные заголовки).

Паттерн: после удаления на сервере — отправить сигнал на инвалидацию в CDN (CloudFront/Fastly) из вашего Go-сервиса.

// псевдокод: инвалидация пути в CDN после удаления пользователя
func purgeCDN(userID string) error {
  // вызов SDK/HTTP API CDN-провайдера
  reqBody := strings.NewReader(`{"paths":["/users/` + userID + `"],"type":"invalidate"}`)
  req, _ := http.NewRequest("POST", "https://cdn.example/api/invalidate", reqBody)
  req.Header.Set("Authorization", "Bearer "+os.Getenv("CDN_TOKEN"))
  _, err := http.DefaultClient.Do(req)
  return err
}

3. Балансировщик: purge ключей

Если используете NGINX/Varnish как кэш перед сервисами — включите адресуемый cache key (например, по X-User-ID) и выполняйте purge на удаление

# пример идеи: привязка кэш-ключа к пользователю
proxy_cache_key "$scheme$request_method$host$request_uri$user_id";

4. Messaging: retention и перезапись по ключу

Персональные данные лучше вообще не класть в сообщения. Если необходимо:

• Выносите PII в secure-storage и передавайте только ссылку/ID.

• Для Kafka — короткий retention.ms и/или compact topics (перезапись по ключу).

// kafka-go: запись "затирающего" сообщения (compacted topic)
msg := kafka.Message{
  Key:   []byte("user:123"),
  Value: []byte("{}"), // пустые поля вместо PII
  Headers: []kafka.Header{{Key: "event", Value: []byte("user.redacted")}},
}
err := writer.WriteMessages(ctx, msg)

5. Сервисы: согласованная инвалидация кэша

Правило: сначала удаляем/редактируем источник, затем инвалидируем все кэши, которые могут содержать копии.

// cache-aside с Redis: сначала БД, затем кэш
func DeleteUser(ctx context.Context, db *sql.DB, rdb *redis.Client, id int64) error {
  tx, err := db.BeginTx(ctx, nil); if err != nil { return err }
  if _, err := tx.ExecContext(ctx, "DELETE FROM users WHERE id=$1", id); err != nil {
    tx.Rollback(); return err
  }
  if err := tx.Commit(); err != nil { return err }

  // Инвалидация всех связанных ключей
  keys := []string{
    fmt.Sprintf("user:%d", id),
    fmt.Sprintf("user:%d:profile", id),
    fmt.Sprintf("user:%d:permissions", id),
  }
  if err := rdb.Del(ctx, keys...).Err(); err != nil { return err }

  return nil
}

➡️ Часть 2

🐸Библиотека Go-разработчика

#буст

🗑 Как действительно удалять чувствительные данные в системах с кэшем. Часть 2

Продолжаем удалять данные из кэша.

➡️ 1 часть

6. Distributed Cache: TTL + массовая очистка

Выстраивайте строгую схему ключей и при удалении — удаляйте все производные ключи.

// go-redis: массовая очистка по шаблону (осторожно с KEYS/SCAN на больших объёмах)
func PurgeUserKeys(ctx context.Context, rdb *redis.Client, id int64) error {
  pattern := fmt.Sprintf("user:%d*", id)
  iter := rdb.Scan(ctx, 0, pattern, 1000).Iterator()
  var batch []string
  for iter.Next(ctx) {
    batch = append(batch, iter.Val())
    if len(batch) == 500 {
      if err := rdb.Del(ctx, batch...).Err(); err != nil { return err }
      batch = batch[:0]
    }
  }
  if err := iter.Err(); err != nil { return err }
  if len(batch) > 0 { return rdb.Del(ctx, batch...).Err() }
  return nil
}

7. Full-Text Search: delete + refresh + мердж сегментов

Удалили документ в БД — обязательно удалите его копию в индексе и дождитесь применения.

// elastic/go-elasticsearch: удаление документа и ожидание refresh
func EsDeleteUser(ctx context.Context, es *elasticsearch.Client, id string) error {
  res, err := es.Delete("users", id, es.Delete.WithRefresh("wait_for"))
  if err != nil { return err }
  defer res.Body.Close()
  return nil
}

Периодически запускайте force merge (операционно, не на горячем трафике), чтобы физически убрать «мертвые» сегменты.

8. База данных: очистка данных и следов

В самой БД есть несколько мест, куда попадают копии: WAL/Redo, buffer pool, материализованные представления, транзакционные/репликационные логи.

Минимальный чек-лист (PostgreSQL в примерах):

• DELETE/UPDATE данных.
• Обновление/перестроение materialized views.
• Политики хранения логов (WAL/archive) и VACUUM (FULL), ANALYZE.
• Очистка репликационного слота/логов при необходимости.

-- 1) Удаление
DELETE FROM users WHERE id = $1;

-- 2) Обновление материализованных представлений
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_user_stats;

-- 3) Вакуум для физического освобождения (по оконным периодам, не на пике)
VACUUM (VERBOSE, ANALYZE) users;
-- В крайних случаях:
-- VACUUM FULL users; -- блокирует таблицу, используйте осторожно

-- 4) Политики логов/архива
-- настройте wal_keep_size, archive_timeout и ротацию архивов под SLA удаления

9. Согласованная оркестрация удаления: событийный подход

Надёжный способ: one-shot Use-Case «EraseUser», который последовательно триггерит очистку по всем слоям и ведёт аудит.

type Eraser interface {
  EraseInDB(ctx context.Context, userID string) error
  EraseInRedis(ctx context.Context, userID string) error
  EraseInSearch(ctx context.Context, userID string) error
  EraseInCDN(ctx context.Context, userID string) error
  EraseInBrokers(ctx context.Context, userID string) error
}

func EraseUser(ctx context.Context, e Eraser, userID string) error {
  steps := []func(context.Context, string) error{
    e.EraseInDB,
    e.EraseInRedis,
    e.EraseInSearch,
    e.EraseInCDN,
    e.EraseInBrokers,
  }
  for _, step := range steps {
    if err := step(ctx, userID); err != nil {
      // логируем, шлём алерты, можно ретраить по политике
      return fmt.Errorf("erase step failed: %w", err)
    }
  }
  return nil
}

«Гарантированное» удаление — это оркестрация инвалидации по всем слоям с чёткой политикой хранения и короткими TTL, плюс периодическое физическое обслуживание (VACUUM/force-merge/compaction).

🐸Библиотека Go-разработчика

#буст

Как это закрыть?

🐸Библиотека Go-разработчика

#развлекалово

😅 Чеклист синдрома самозванца

Иногда кажется, что все вокруг гении, а вы случайно прошли собеседование? Вот быстрый тест:

1️⃣ Чувство, что вы «не заслужили» успеха

2️⃣ Есть ощущение, что скоро все поймут, что вы «ничего не знаете»

3️⃣ Склонны обесценивать то, что сделали: «Это ерунда, любой бы справился»

4️⃣ Часто думаете, что коллеги умнее и продуктивнее вас

5️⃣ Считаете, что должны знать и уметь всё, иначе — вы некомпетентны

Если вы отметили 3+ пункта, синдром самозванца может влиять на вашу работу и настроение.
Первый шаг — признать его, второй — учиться объективно оценивать свои результаты.

🐸Библиотека Go-разработчика

#буст

🧠 Построение решения с алгоритмами

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

Нужно быстро найти элемент? Если данные редко меняются — используйте бинарный поиск по отсортированному массиву. Если часто — подумайте о хэш-таблице.

Нужно обрабатывать большие объёмы данных? Начните с O(n) или O(n log n) алгоритмов (например, быструю сортировку). Избегайте O(n²) решений на миллионах элементов — они сломаются на проде.

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

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

💬 А как вы выбираете алгоритмы? Сначала теорию, или сразу быстрый прототип и бенчмарки? Делитесь опытом 👇

P.S. Если хотите задать вопрос сообществу или поделиться историей, заполните нашу гугл-форму.

🐸Библиотека Go-разработчика

#междусобойчик

💡 Мини-видеообзор Go 1.25

В этом релизе язык стал чище, быстрее и удобнее. Убрали концепцию "core type", улучшили сборщик мусора — теперь он работает до 40% быстрее в реальных приложениях.

В видео быстро про все фичи и улучшения.

➡️ Смотреть видео

🐸Библиотека Go-разработчика

#буст

🧑‍💻 Почему конкурентность ≠ параллелизм

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

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

Параллелизм — это реальное выполнение нескольких задач одновременно, используя несколько процессорных ядер.

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

— Конкурентность может быть реализована на одном ядре, где задачи переключаются друг с другом.

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

В некотором смысле, конкуренция — это управление временем, а параллелизм — это управление ресурсами.

Несмотря на различия, конкуренция и параллелизм часто работают вместе.

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

🐸Библиотека Go-разработчика

#буст

💡 Unit-лид и Technical Owner в команде

Традиционная модель управления «тимлид + продакт-менеджер» показывает ограничения в современных реалиях:
• Масштаб разработки — команды растут до 50-100+ человек
• Сложность продуктов — многокомпонентные системы с десятками интеграций
• Скорость изменений — релизы каждые 2-4 недели вместо квартальных обновлений.

На смену приходят роли, ориентированные на продуктовое мышление вместо простого исполнения задач.

➡️ Про эти роли в статье

🐸Библиотека Go-разработчика

🧑‍💻 Как должна расти зарплата разработчика

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

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

💬 Как вы думаете, насколько быстро должна расти зарплата разработчика? И когда рост должен закончится?

🐸Библиотека Go-разработчика

#междусобойчик

📰 Дайджест недели

Вторая неделя осени прошла и мы собрали для вас материалы, которые вы могли пропустить.

— Как находить баги, просто читая код

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

— tRPC-Agent-Go

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

— Как создать многопользовательскую игру с Pion и WebRTC

WebRTC DataChannels вместе с Go и Ebitengine этот подход позволяет быстро и эффективно строить игры, которые могут работать на разных платформах и устройствах.

— Чествование самых глупых решений в области ИИ

AI Darwin Awards — это награды, которые отмечают самые глупые и неосторожные применения технологий искусственного интеллекта, приведшие к катастрофическим последствиям. В 2025 году номинированы самые эпичные провалы.

— 5 трендов IT-найма 2025

🐸Библиотека Go-разработчика

📌 Шпаргалка по API-дизайну

API — это “дверь” в ваш продукт. Через него общаются сервисы, приложения и даже бизнес-процессы.
Если дверь кривая и скрипит — пользователи не захотят ею пользоваться.

Составили для вас шпаргалку по апи.

1. Ясные имена

• Используйте простые и логичные названия.
• Коллекции — во множественном числе: /users, /orders.

2. Идемпотентность

Повторные запросы ведут к одному и тому же результату. Представьте, что вы удаляете объект дважды подряд: корректный API просто вернёт подтверждение того, что объекта больше нет, а не создаст ошибку или неожиданный результат.

3. Пагинация

Нельзя выдавать тысячи строк ответа одним куском: это тормозит работу и перегружает сеть. Вместо этого нужно разбивать результаты на страницы. Существуют разные стратегии: от простого смещения до курсорной модели.

4. Сортировка и фильтры

Управляйте выборкой через query-параметры:
• Фильтр: /users?status=active
• Сортировка: /users?sort=created_at&order=desc

5. Связи ресурсов

В реальном мире данные редко живут изолированно: пользователи связаны с заказами, товары с категориями и так далее. Поэтому лучше строить маршруты вроде /users/{id}/orders, которые сразу показывают, какие данные связаны между собой.

6. Ограничение запросов

Ограничение вроде «100 запросов в минуту» помогает сохранить стабильность для всех пользователей. Обычно сервер сообщает об этом через заголовки ответа: X-RateLimit-Limit, X-RateLimit-Remaining.

7. Версионирование

API неизбежно меняется: появляются новые поля, меняется структура, иногда от чего-то приходится отказываться. Чтобы не ломать существующих клиентов, используется версионирование: кто-то работает с /api/v1/users, кто-то уже перешёл на /api/v2/users.

Хороший апи — это не только про код.

🐸Библиотека Go-разработчика

#буст