«Типичный программист» публикует материалы о разработке, инженерных решениях и IT-профессиях. В ленте есть объяснения, задачи и новости инструментов.

78 000подписчиков0переходов0просмотров страницы

Подписчики и просмотры публикации — из публичного предпросмотра Telegram; переходы и просмотры страницы — с сайта. Обновлено 16.10.2026

О канале

«Типичный программист» публикует материалы о разработке, инженерных решениях и IT-профессиях. В ленте есть объяснения, задачи и новости инструментов. Публикации разбирают поведение программ и типичные ошибки на конкретных примерах. Обучающие материалы сопровождаются ссылками на статьи и другие проекты редакции.

Аудитория канала

Число подписчиков из публичного предпросмотра Telegram. Сохраняем реальные замеры при обновлении данных. Разрыв линии означает перерыв в замерах более трёх дней.

Первый замер: 78 000 подписчиков (16.10.26). График появится после следующего замера в другой день.

Перед подпиской

Доступ
Публичный канал
Язык публикаций
Русский
Формат
текстовые публикации, фотографии, видео, ссылки. Видны в веб-предпросмотре.
Кому подходит
Программистам и читателям, которые хотят глубже понимать инженерную практику.
Последняя известная публикация
16.10.2026, 13:54:01 МСК
Проверка адреса
Адрес Telegram ответил — 16.10.2026, 15:36:25 МСК. Успешный HTTP-ответ не подтверждает действительность приглашения.
Предпросмотр Telegram
Получен 16.10.2026, 15:36:04 МСК. Это не подтверждает действительность закрытого приглашения.
Редакционная проверка сведений
16.10.2026

Принадлежность канала редакцией не подтверждена.

Как проверяются данные →

История изменений

Сохраняется с момента подключения журнала. Смена адреса сама по себе не подтверждает сохранение владельца.

  • — Доступность адреса: unknown → reachableИсточник: Фоновая HTTP-проверка адреса Telegram

Последние публикации

Обновляются раз в 2 дня
Типичный программист@tproger
Изображение публикации

«Повторим запрос один раз» может превратиться в восемь запросов Представьте цепочку A → B → C → D. Если D ошибается, а каждый предыдущий сервис повторяет вызов один раз, до D в худшем случае дойдут восемь попыток на один исходный запрос. Лимиты ретраев уменьшают усиление, но оно всё ещё накапливается по цепочке. В Uber добавили контекст ошибки: инфраструктура различает сервис, где она возникла, и сервисы, которые лишь передают её выше. Повтор разрешается на границе рядом с источником сбоя, в пределах бюджета. Выше по цепочке ту же ошибку повторно «лечить» уже не пытаются. Так временный сбой сохраняет шанс на успешную повторную попытку, а перегруженный сервис не получает дополнительную лавину от каждого уровня зависимостей.

Типичный программист@tproger
Изображение публикации

Баг появлялся в 0,001% случаев. Виноваты оказались два формата одного ответа MySQL-запрос иногда возвращал пустой результат вместо строк. В Hyperdrive ошибка возникала только с включённым кешем, а поймать её трассировкой долго не удавалось. У Cloudflare нашлось объяснение: два узла могли пользоваться общим кешем, но записывали туда разные байты. Один сохранял ответ в формате Hyperdrive, другой — уже преобразованный под возможности клиентского драйвера. Разница касалась пакетов EOF и OK, обозначающих границы результата. Чужая версия ответа могла выглядеть как преждевременный конец данных или приводить к зависанию. Исправление: всегда хранить в кеше один канонический формат, а преобразование выполнять перед отправкой клиенту. После этого проблема с пустыми ответами исчезла.