🍁 Осенний дайджест

Пришло время собрать интересные материалы первой недели осени.

— Как ускорить тесты и сократить время их выполнения

В новом посте команда Go делится методами оптимизации времени выполнения тестов. Рассматриваются техники параллельного запуска, уменьшения объёма тестовых данных и правильного использования моков.

— Появился новый yamlgoyaml для Go

Сообщество Go объявило о форке популярной библиотеки GoYaml, теперь под названием yamlgoyaml. Форк направлен на улучшение совместимости с современными версиями Go, исправление багов и оптимизацию производительности.

— Методы по умолчанию в Go

— Cup o’ Go про актуальное

— Обновления Go-безопасности

— Строим банк с нуля

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

😎 Топ-вакансий для 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-разработчика

#буст