Базы данных медленные.
Пользователи нетерпеливые.
Redis существует.
Проблема решена.

👉 @BackendPortal

Git tip

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

git rm --cached <file>

После этого файлы станут untracked. Добавь их в .gitignore и сделай новый коммит, чтобы полностью прекратить их трекинг.

👉 @BackendPortal

GPT-5 это не одна модель.

Это единая система из нескольких моделей, защитных контуров и роутера в реальном времени.

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

Instant mode отправляет запрос напрямую в быструю нерезонирующую модель GPT-5-main. Она оптимизирована под минимальную задержку и подходит для простых или низкорисковых задач типа коротких объяснений или переписываний текста.

Thinking mode использует рассуждающую модель GPT-5-thinking, которая делает несколько внутренних шагов перед финальным ответом. Это повышает корректность на сложных задачах вроде математики или планирования.

Auto mode добавляет роутер в реальном времени. Легковесный классификатор смотрит на запрос и решает, использовать GPT-5-main или GPT-5-thinking, когда нужно более глубокое рассуждение.

Pro mode не использует другую модель. Он берет GPT-5-thinking, но сэмплирует несколько попыток рассуждения и выбирает лучшую с помощью reward model.

Во всех режимах safeguards работают параллельно на разных стадиях. Быстрый тематический классификатор определяет, высокорисковая ли тема, затем reasoning monitor применяет более строгие проверки, чтобы заблокировать небезопасные ответы.

👉 @BackendPortal

Большинство систем детектят падение ноды или мастера простым polling-ом, и хотя звучит это очевидно, у подхода есть интересная проблема с надежностью

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

На бумаге все ок, но у всех этих методов одна и та же слабость: а что если ошибается сам наблюдатель?

В распределенной системе сетевые глюки это норма. Временная потеря пакетов, косяки маршрутизации или частичные сетевые партиции легко делают здоровую ноду “недоступной” именно для наблюдателя. Обычно это фиксят ретраями: повторяют проверку несколько раз и объявляют фейл после n-го подряд провала.

И тут появляется классический компромисс.

Если n маленькое (или polling очень частый), детект получается быстрым, но растет число false positive. Короткий сетевой чих может запустить ненужный failover, который иногда разрушительнее исходной проблемы.

Если n большое (или интервалы polling длиннее), false positive меньше, но реальные падения детектятся дольше. А эта задержка напрямую увеличивает даунтайм.

Но если у тебя уже есть кластер, можно мыслить надежнее.

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

Такой consensus-подход снижает риск false positive из-за сетевых партиций. Даже если один наблюдатель потерял связность, остальная часть кластера все равно дает более точную картину здоровья системы.

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

👉 @BackendPortal

Когда один из серверов падает, дальше все зависит от того, есть ли у тебя load balancer и как он настроен.

▪️Если есть load balancer

1. Health checks. Балансер постоянно пингует бэкенды (HTTP endpoint типа /health, TCP-check, gRPC-check). Если сервер не отвечает или возвращает плохой статус, он помечается как unhealthy.

2. Трафик на него перестают слать. Балансер выкидывает упавший инстанс из пула и перенаправляет запросы на живые сервера.

3. Что увидит пользователь

Если живых серверов достаточно, пользователь почти ничего не заметит (максимум краткий пик задержек).
Если это был единственный сервер, или остальные уже под нагрузкой, будет ошибка/таймаут (обычно 502/503/504).

4. Сессии и состояние

Если у тебя sticky sessions (привязка пользователя к одному серверу) и именно он умер, у пользователя может “слететь” сессия, если она хранилась в памяти сервера.
Правильнее хранить сессии/кеш/стейт внешне (Redis, DB), тогда падение инстанса не ломает логин и корзину.

5. Автовосстановление. В нормальной прод-схеме оркестратор (Kubernetes/ASG/VM supervisor) поднимет новый инстанс, и балансер снова начнет слать на него трафик после успешных health checks.

▪️Если load balancer нет

Все запросы идут в один сервер.
Сервер упал = приложение лежит полностью до ручного/автоматического рестарта.

Load balancer делает так, чтобы падение одного сервера было “не трагедия”, а “минус один из пула”. Без балансера падение сервера почти всегда равно даунтайму.

👉 @BackendPortal

SQL-хак, о котором мало кто знает

Знал, что можно юзать FILTER как альтернативу CASE в агрегатах?

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

Если твой SQL-движок поддерживает FILTER (PostgreSQL, SQLite, DuckDB), попробуй.

CASE или FILTER? Что тебе больше нравится? 😆

👉 @BackendPortal

Git Tip

Нужно откатить изменения из конкретного коммита, но не переписывать историю? Используй:

git revert <commit-hash>

git revert не удаляет коммит, а создаёт новый коммит, который “отменяет” изменения выбранного. Отлично подходит для общего репозитория и веток, где уже есть чужие pull'ы.

👉 @BackendPortal

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

Skip list (список с пропусками) это многоуровневый linked list: вставка по скорости как у обычного LL, но поиск намного быстрее.

Полезны ли они? Да. RocksDB использует skip list для своей LSM memtable.

👉 @BackendPortal

В Go, когда тестируешь POST-хендлер, тебе нужен body запроса. Используй strings.NewReader с JSON-строкой, чтобы получить io.Reader. Хендлер прочитает это как настоящий body. Интерфейс тот же, реальный HTTP не нужен.

👉 @BackendPortal

В Go можно читать из файлов, строк и сетевых соединений одним и тем же кодом. Секрет в io.Reader.

Если тип умеет отдавать байты, он реализует io.Reader. Принимай io.Reader и твой код будет работать везде.

Дизайн через интерфейсы: завязывайся на поведение, а не на источник данных.

👉 @BackendPortal

Университет Хельсинки выложил бесплатный курс MOOC по Python

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

👉 @BackendPortal

Git-лайфхак

Хочешь нормальный граф коммитов по репе одной командой:

git log --oneline --graph --decorate --all

👉 @BackendPortal

В Go 1.26 в пакет reflect завезли итерируемые (range-able) итераторы.

Плюс добавили новые методы:

Type.Methods()
Type.Ins()
Type.Outs()
Value.Fields()
Value.Methods()

Теперь с рефлексией можно работать заметно удобнее и ближе к обычному Go-коду, без лишней возни с индексами и слайсами.

👉 @BackendPortal

Вот штука, которая звучит немного контринтуитивно про B+ деревья: вставлять ключи в отсортированном порядке реально быстро, но есть скрытая цена.

Когда ты вставляешь ключи последовательно (1, 2, 3, 4...), B+ дерево почти ничего не “перетряхивает”. Узлы не приходится постоянно делить и ребалансить: каждый новый ключ улетает в самый правый лист. Вставки выходят супер дешевыми: минимум ребалансинга, минимум затронутых дисковых блоков.

Но плата за это такая: появляется жесткая внутренняя фрагментация.

Поскольку все вставки идут по правому краю, “левые” узлы редко добиваются до полной емкости. В итоге в хранилище лежит куча полупустых страниц, которые жрут место. Страница, которая могла бы держать 100 ключей, по факту держит 50–60, и это потом размазывается по всему дереву.

Случайные вставки, наоборот, распределяют ключи равномернее по страницам. Они медленнее, потому что будут сплиты/ребаланс, зато по месту всё намного эффективнее.

Так что если ты делаешь bulk load, отсортированная вставка дает скорость. Но если тебе важна плотность (память/диск) в долгую, имеет смысл перемешать ключи или использовать специальные bulk-loading алгоритмы, которые пакуют страницы плотнее.

Короче, как обычно: “лучшего способа” на все случаи нет :)

👉 @BackendPortal

Git tip : узнать, кто последний правил каждую строку файла, можно командой:

git blame <filename>

Примечание: работает только для того, что уже закоммичено. Незакоммиченные правки (текущие изменения в рабочем дереве) в blame не попадут.

👉 @BackendPortal

SSH-мультиплексирование в Go: SFTP-передачи в 14 раз быстрее по одному соединению

Код: https://github.com/MYK12397/sftp-go

SFTP работает поверх SSH, а SSH из коробки мультиплексированный протокол. Одно TCP-соединение SSH может одновременно нести сотни независимых каналов. Каждый open/read/close файла это отдельный канал, а SSH-слой сам “перемежает” их по проводу.

Я сам это не осознавал, пока мой скрипт для перекачки файлов не ускорился с 22 минут до 94 секунд, при том что я не открывал ни одного дополнительного соединения.

Как работает SSH-мультиплексирование

Когда вы вызываете sftpClient.Open() в Go-пакете pkg/sftp, создается новый SSH-канал, а не новое соединение. Транспортный слой SSH мультиплексирует все каналы поверх одного TCP-сокета. То есть 80 горутин (мой кейс) могут параллельно читать разные файлы, все разделяя один sftp.Client.

http://sftpClient.Open() это ключевая строка. Каждый вызов открывает новый SFTP file handle, который мапится на новый SSH-канал. SSH-библиотека (golang.org/x/crypto/ssh) прозрачно обрабатывает мультиплексирование этих каналов, перемешивая read-пакеты всех 80 горутин по одному TCP-сокету.

При этом нет конкуренции за mutex на самом sftp.Client(). В библиотеке внутренние локи на уровне пакетов, а не на уровне файлов. Горутина A читает байты из файла 1 и не блокирует горутину B, которая в это время открывает файл 2.

👉 @BackendPortal

sqlc это генератор кода для Go на этапе генерации. Ты пишешь SQL-запросы, а sqlc парсит их вместе со схемой и на основе этих запросов генерирует типобезопасный Go-код (структуры, функции).

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

Link: https://github.com/sqlc-dev/sqlc

Поправка: это не генерация на “compile-time”. Это отдельный шаг генерации, который ты запускаешь вручную (или в CI) перед компиляцией:

sqlc generate      # pre-build step
go build ./...

👉 @BackendPortal

В этом видео разбирают асинхронное чтение (read IO) в Postgres 18.

0:00 Вступление
1:30 Синхронные и асинхронные вызовы
3:00 Синхронный IO
6:30 Асинхронный IO
10:00 Синхронный IO в Postgres 17
17:20 Почему Async IO в Postgres 18 это непросто
20:00 io_method: worker
23:00 io_method: io_uring
29:30 io_method: sync
31:08 Async IO еще не готов!
31:30 Поддержка backend writers
32:36 Улучшения worker io_method
33:00 Поддержка direct IO

👉 @BackendPortal

Никогда не запускай запросы без таймаута.

Без него один “вредный” запрос или всплеск нагрузки легко приводит к затыкам и даже к даунтайму приложения. Давай разберем, почему.

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

Он не только будет жрать ресурсы, но и резко увеличит число одновременных транзакций. В итоге мы упремся либо в лимит соединений, либо в лимиты по транзакциям, либо просто выжмем 100% CPU / IOPS у базы.

Теперь та же ситуация, но мы ставим таймаут 250 мс на каждую транзакцию (на стороне базы), а на стороне приложения делаем ретраи с экспоненциальным backoff + jitter. Так мы ограничиваем радиус поражения от одного запроса. Долгие запросы будут прибиваться, а backoff-логика снижает риск эффекта “стада” (thundering herd).

И если мониторить эти таймауты, можно быстро найти проблемный запрос и откатить изменение.

👉 @BackendPortal

Умоляю: не юзайте CTE

CTE это не медалька и не повод гордиться.

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

Если ваш CTE не:
❌улучшает читаемость
❌помогает разложить сложность
❌отделяет логические шаги

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

CTE это просто инструмент. И как любой инструмент, не надо им злоупотреблять💚

👉 @BackendPortal

React Doctor уже тут

Сканируй свой React-код на анти-паттерны:

▪️лишние useEffect-ы
▪️исправляет проблемы с доступностью (a11y)
▪️prop drilling вместо context / композиции

Запускается как CLI или как агент skill. Гоняешь снова и снова, пока всё не проходит. Полностью open source.

Запусти это в терминале, чтобы попробовать:

npx -y react-doctor@latest

исходный код

👉 @BackendPortal