Отличная дискуссия получилась — и да, большинство гуру Postgres ответило верно! Давайте спокойно разберёмся, почему.

«Совсем плохой» способ — просто сделать колонку NOT NULL:

ALTER TABLE some_big_table
  ALTER COLUMN foo_field SET NOT NULL;

Почему так делать очень плохо на большой таблице?

Чтобы убедиться, что в столбце нет NULL, Postgres сканирует всю таблицу. Такие изменения вокруг ADD CONSTRAINT/SET NOT NULL обычно требуют ACCESS EXCLUSIVE — самый сильный DDL-лок, конфликтующий со всеми операциями, включая чтения. Это легко превращается в stop the world на таблице, если операция длится долго.

Правильный подход: через NOT VALID → VALIDATE

Идея — разделить «включить проверку для новых записей» и «проверить историю» на два шага.

1. Добавляем ограничение без проверки истории (не блокирует обновления надолго):

ALTER TABLE some_big_table
  ADD CONSTRAINT some_big_table_foo_field_not_null
  CHECK (foo_field IS NOT NULL) NOT VALID;

С флагом NOT VALID добавление не сканирует таблицу и может быстро зафиксироваться. Новые/изменённые строки уже обязаны удовлетворять условию.

2. Отдельно валидируем историю:

ALTER TABLE some_big_table
  VALIDATE CONSTRAINT some_big_table_foo_field_not_null;

VALIDATE CONSTRAINT сканирует только существующие строки и берёт уже SHARE UPDATE EXCLUSIVE (гораздо мягче), так что записи не блокируются так сурово, как при прямом SET NOT NULL.

Что именно могло заблокировать таблицу в нашем кейсе?

Наша SQL миграция выглядит так (все в одной транзакции):

BEGIN;

ALTER TABLE ... ADD CONSTRAINT ... CHECK (...) NOT VALID;
ALTER TABLE ... VALIDATE CONSTRAINT ...;

COMMIT;

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

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

В таком случае:
- Мы берем блокировку ACCESS EXCLUSIVE для добавления CONSTRAINT
- Далее эта блокировка будет удерживаться до конца работы транзакции
- Валидация нагрузки происходит долго, что приводит к тому, что транзакция превращается в долгоживующую => таблица заблокирована надолго.

Практический вывод: Делайте ADD CONSTRAINT ... NOT VALID и фиксируйте сразу (быстрый COMMIT). А VALIDATE CONSTRAINT запускайте отдельной миграции и, желательно, в спокойный период.

А чтобы не переживать насчет ваших миграций, вы можете настроить линтер: squawkhq

Cloudflare нашли редчайший баг — прямо в компиляторе Go для ARM64

Да, это не опечатка: не рантайм, не гасе condition в их коде, а чистый косяк в сгенерированном машинном коде Go. И баг был настолько редким, что проявиться он мог только в инфраструктуре масштаба Cloudflare при 84 миллионах НТТР-запросов в секунду.

Не завидую парням, сам пол недели фикшу баги в драйвере на go…

Признавайтесь, у кого так было?)

⚠️ Когда API молчит - страдает клиент

Представьте, у вас есть метод:

rpc GetUsers(GetUsersRequest) returns (GetUsersResponse);

message GetUsersRequest {
  repeated string ids = 1;
  optional string city = 2;
  int32 page = 3;
  int32 page_size = 4;
}

Вы вызываете GetUsers с 200 идентификаторами, ожидаете получить всех.
А сервер молча возвращает 100.
Без ошибки и без всякого предупреждения.

Почему? Да потому что в коде спрятан жёсткий limit = 100, о котором никто не знал.

Такие вещи ломают доверие к API.
Когда контракт неявный, клиенту остаётся только гадать: это баг, фильтр, лимит, пагинация или оптимизация?

А ещё хуже, когда такое поведение всплывает на production, и выясняется, что система теряла данные неделями (классика жанра).

💡 Хорошее API — прозрачное API.

— если есть лимиты, они должны быть явно задокументированы или возвращаться в ответе;
Часто вижу, что разработчики в gRPC не оставляют никаких комментариев в .proto - поверьте, просто спецификации НЕДОСТАТОЧНО. Клиент должен понимать не только что вызвать, но и чего ожидать.

— если что-то отфильтровано, клиент должен понимать, почему;
даже простая метка filtered=true , partial=true или список missing_ids уже делает API дружелюбнее.

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

Хорошо спроектированное и описанное API спасает от множетсво багов и недопониманий в будущем. Проводите ревью API тщательно, господа.

P.S. На мой взгляд хорошее gRPC API описано примерно так:

// Pagination - пагинация
message Pagination {
  option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
    json_schema: {
      noscript: "Pagination"
      denoscription: "Пагинация"
    }
  };

  // page_number - номер страницы. По умолчанию 1
  uint64 page_number = 1 [
    json_name = "page_number",
    (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {default: "1"}
  ];

  // page_size - размер страницы. По умолчанию 50
  uint64 page_size = 2 [
    json_name = "page_size",
    (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_field) = {default: "50"}
  ];
}

// PageInfo - информация о странице
message PageInfo {
  option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
    json_schema: {
      noscript: "PageInfo"
      denoscription: "Информация о странице"
    }
  };

  // total_count - общее кол-во записей
  uint64 total_count = 1 [json_name = "total_count"];

  // count - кол-во полученных записей на текущей странице
  uint64 count = 2 [json_name = "count"];

  // page_number - текущий номер страницы
  uint64 page_number = 3 [json_name = "page_number"];

  // page_total - общее кол-во страниц
  uint64 page_total = 4 [json_name = "page_total"];

  // page_size - размер страницы
  uint64 page_size = 5 [json_name = "page_size"];
}

А вы как считаете?

Go давно вышел за рамки веба. На нём уже пишут базы и прокси, видео-сервисы, блокчейн-узлы, компиляторы и даже игры — и делают это не ради эксперимента, а в продакшене.

В новом сезоне онлайн-конференции Podlodka Go Crew (10-14 ноября) разбираемся, как язык открывает путь к более сложным и интересным задачам — от инфраструктуры и DevEx до real-time и системных сервисов — и почему это отличный шанс вырасти как инженер.

В программе:

⚙️ Как сделать быстрый клиент для базы данных. Разберём, как реализовать асинхронное взаимодействие с БД на Go на примере Tarantool, какие оптимизации реально ускоряют код и как эволюционировать от наивного решения до производительного, — вместе с Олегом Жуковцом (VK Tech).

🌐 Как управлять сетями прямо из Go. Посмотрим, как устроены интерфейсы в Linux, как ими управлять и собирать сложные топологии без боли. Узнаем, как работает CNI в Kubernetes и почему мир виртуальных сетей держится на Go, в докладе Даниила Губанова (Точка).

🔒 Блокчейн как real-time система. Без маркетинга: только Go, каналы, горутины и контроль над хаосом. Разберём блокчейн как инженерную задачу: сеть, криптографию и конкуррентность — вместе с Ниной Лукиной (01tech).

💬 Круглый стол «Когда Go выходит за рамки». Поговорим с нанимающими тимлидами о том, кого ищут под нестандартные Go-задачи: где важны инженерная зрелость, осознанность и умение разбираться в системах под капотом, — и как туда попасть.

💡Тем, кто хочет вырасти из CRUD-сервисов и попробовать себя в системных и инфраструктурных задачах, будет особенно полезно.

🗓 Билеты уже на https://podlodka.io/gocrew

А с моим промокодом leoscode получите скидку 🎁

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

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

Почти синхронно мир наблюдал еще один эпизод, на этот раз связанный с Cloudflare. Согласно их официальному отчёту, проблема началась после обновления конфигурации, затронувшего один из ключевых маршрутизаторов. Изменение привело к перегрузке маршрутизации, из-за которой часть сетевого трафика попросту перестала доходить до нужных узлов. В результате множество сайтов и сервисов, опиравшихся на Cloudflare как на основной сетевой слой, оказались недоступны или работали с серьёзными перебоями.

Именно в такие моменты становится ясно, насколько много держится на том, что обычно называется инженерным вниманием к деталям.

Эти истории объединяет одно: вопреки общей вере в безупречность глобальных платформ, за ними стоят люди. Со всеми сильными сторонами, профессионализмом и колоссальным опытом, но и с той самой человеческой склонностью к ошибке, от которой никто не застрахован. И если даже AWS и Cloudflare сталкиваются с провалами крупного масштаба, то каждому из нас стоит задуматься о собственной практике.

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

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

Найм в IT требует реформ

Всё чаще замечаю, что текущая система отбора кандидатов и проведения собеседований разработчиков не работает — или работает исключительно по теории вероятности!

Не раз видел, как сильных инженеров «списывают» буквально на скрининге из-за того, что они не знают какие-то тонкости языка или не смогли ответить на хитрый вопрос, который по сути бесполезен.
При этом, лично зная таких инженеров, видел, как они могут «в одну каску» затащить сложный проект и довольно быстро разобраться в любой технологии самостоятельно.

Бывает и так, что кандидат — отличный «книжный эксперт»: натренированный на собеседованиях (в лучшем случае, а в худшем — благодаря ChatGPT), он блестяще проходит интервью и выглядит увереннее остальных. А потом выходит на работу и… решения получаются с багами или просто черновыми, задачи задерживаются, требуется постоянный контроль за разработчиком и валидация его решений.

Про отбор резюме на уровне HR молчу — это отдельная проблема индустрии. От части это и вина самих разработчиков: резюме нужно уметь составлять грамотно (отдельный вид искусства так сказать). Всё осложняется тем, что в больших компаниях есть «задачники», куда какие-то эксперты когда-то занесли «оригинальные» вопросы, и теперь всех гоняют по ним, как на экзамене. Но главный вопрос — на что они нацелены? Создают ли эти вопросы нужную воронку? Возможно, раньше так и было, но сейчас… сейчас нужно что-то новое.

Знаю, что в последнее время некоторые руководители практикуют очные собеседования (дабы ChatGPT не смог помочь), но, к сожалению, это не всегда возможно. А что остаётся? Возможно, стоит просматривать GitHub кандидата? — так не все туда что-то дельное пушат. Может быть, тогда live-кодинг реальных задач? — одного часа может и не хватить. Или техническое тестовое задание из доменной области «на дом» со сроком выполнения? (Однажды я выполнял такое задание — было интересно: смог поработать с CGO и TCP-протоколом на низком уровне. Правда, фидбэк по выполнению так и не получил…)

Я пока нахожусь в поиске лучших вопросов и задач, которые нацелены на проверку именно нужных компетенций.

Были ли у вас интересные, необычные задачи или вопросы на собеседовании, которые вам запомнились?