Замена Redis на MySQL в Shopify: устройство резервов и поиск дефицита соединений

На время оплаты Shopify резервирует товары, чтобы два покупателя не забрали последнюю единицу. Перенос резервов в MySQL позволил списывать товар и снимать резерв одной транзакцией. Но первые попытки упирались в конкуренцию за одну строку с количеством товара.

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

Запросы ускорились, но соединений всё равно не хватало. Метки в SQL-запросах и замеры на прокси показали: другие части оформления заказа удерживали соединения слишком долго. В разборе миграции Shopify есть эта диагностика, подбор ключей и уровня изоляции, а также проверка двух систем в параллельной работе.

#веб

Как метрики помогли найти ошибку в ИИ-оценщике размера видео

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

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

В материале есть код сбора метрик и настройка панели. Замеры идут из публичного браузерного конвертера, сами видео, имена файлов и адреса на сервер не отправляются.

#ии #веб

Миллион запросов в секунду мимо общего балансировщика

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

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

На пике напрямую пошло больше миллиона запросов в секунду. По данным команды, задержки стабилизировались, а парк Skipper для этих маршрутов сократился с 50+ копий до восьми. Сам Skipper никуда не делся: внешние запросы остались у него. Тут убрали один лишний круг внутри системы, а не переписали весь входной трафик.

Сжатие временных рядов в Axiom: меньше места на диске, больше работы процессору

Gorilla сжимает измерения по мере поступления и требует строгого порядка по времени. У клиентов Axiom каждую секунду приходят тысячи опоздавших точек. В разборе альтернативы Gorilla команда показывает, как хранить такие данные и сколько это стоит.

Новые измерения попадают в несжатый буфер, где их сортируют по времени. Заполненный буфер сжимают пакетом и переносят в сжатую часть. Время отмечают битовой картой: каждый установленный бит указывает на момент с измерением. При запросе карта помогает выбирать точки из нужного диапазона.

На данных Axiom хранилище обычно занимает 30–50% от размера Gorilla. Но оптимизированная Gorilla примерно в 15 раз эффективнее по CPU, то есть затратам процессора на кеш. Память кеша чаще составляет 70–100% от Gorilla; все цифры зависят от нагрузки.

#облака

Пять лет новых функций. Сколько памяти теперь ест libcurl?

Обычно от такого сравнения ждёшь грустного графика. Дэниел Стенберг, автор curl, сопоставил libcurl 7.75.0 и 8.19.0-DEV и получил смешанную картину: структура одного соединения уменьшилась с 1472 до 912 байт, а две другие выросли.

Для десяти передач и двадцати открытых соединений сумма этих трёх структур оказалась на 10 000 байт меньше. Но при скачивании одного файла на 512 МБ пик памяти вырос на 1,6%, а число аллокаций увеличилось с 96 до 107. Один красивый показатель тут легко спрятал бы второй.

В тестах curl теперь есть проверка размеров пятнадцати важных структур. Превысил лимит — сборка упала, дальше приходится объяснять рост. Замеры Стенберга сделаны на Linux с HTTP без TLS. Память криптографической библиотеки в эту историю не входит.

Общая папка для работы Claude Code и Codex

Луи-Франсуа Бушар собрал заметки, инструкции-скиллы, скрипты и итоги встреч в Obsidian. Его связка устроена так:

Папка хранит исходные материалы и решения
↓
Индекс указывает, где искать данные для задачи
↓
Claude Code планирует работу
↓
Codex выполняет задачи по его вызову

В описании этого рабочего процесса Бушар объясняет, зачем даёт агенту сведения для конкретной задачи. Начать предлагает с общей папки, короткого индекса и одного повторно используемого скилла.

#ии #инструменты

Сортировку ускорили в 26 раз. Общий алгоритм просто знал слишком мало

У Axiom разные колонки сортировались одинаково: сравнивали значения по два, каждый раз превращая их во внутренний общий тип. Удобно. Только колонка с уровнями логов уже знала, что разных значений в ней не больше пятнадцати. А сортировка этой подсказкой не пользовалась.

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

На блоках примерно по 65 тысяч строк, на Apple M4, ускорение разных типов составило 2–26 раз. Максимум достался enum. Это не обещание ускорить любую сортировку: выигрыш появился там, где данные уже имели полезную структуру. Её не пришлось придумывать, достаточно было перестать терять при каждом сравнении.

Завтра иду на GoCloud Tech 2026

Кому интересно узнать какие-нибудь подробности с мероприятия? Могу потом рассказать отдельно!

И, конечно, можем увидеться там, если вы тоже идёте.

Python обработал 7,6 ГБ JSON за 0,12 секунды

Здесь интересно, куда уходило время. Дэниел Лемир, исследователь производительности, взял 2,2 млн событий GitHub, чтобы посчитать открытые PR по языкам. А Python при обычном разборе создавал кучу словарей, списков и строк, которые для этой задачи вообще не нужны.

В эксперименте с fastsimdjson и lazy=True Python-объекты создаются только для запрошенных полей. Сборка Python без GIL позволяет обрабатывать события в 64 потоках внутри одного процесса. У каждого потока свои счётчики, в конце их складывают. Зачем собирать весь объект, если нужна только малая часть?

У Лемира получилось около 0,12 секунды. Стенд: два Xeon Gold 6548N, 64 ядра, free-threaded Python 3.14.6 и fastsimdjson 0.6.0. Все 7,6 ГБ уже распакованы в RAM, чтение с диска и распаковка в замер не входят. Это лучший из семи прогонов, одинаковую статистику сверили всеми методами.

Зачем Figma рисует невидимый HTML рядом с холстом

На холсте Figma может быть сотня слоёв, а для экранного диктора всё это долго выглядело как один большой объект. Рисование взял на себя движок Figma. Вместе с ним исчезла и привычная HTML-структура, по которой браузер объясняет интерфейс человеку.

Команда собрала Mirror DOM: невидимые элементы с ролями, подписями и расположением слоёв. Между ними и холстом синхронизируют фокус. Выбрали объект мышью — диктор знает, где вы. Перешли диктором к другому элементу — выделение на холсте тоже поменялось.

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

Историю звёзд GitHub собирали за 2500 запросов. Теперь хватает 24

Чтобы построить график популярности React, сервису приходилось выкачать около 251 тысячи пользователей, оставить даты и выбросить имена. Плюс каждый запрос заново пересчитывал все звёзды ради пагинации.

В новом API GitHub возвращаются дневные счётчики. Но одного GROUP BY мало: если сначала сгруппировать всю историю и только потом применить LIMIT, база всё равно сделает лишнюю работу.

Поэтому запрос сначала выбирает индексированный диапазон дат, затем считает звёзды внутри него. Одна страница покрывает до 30 недель; для React вся история укладывается примерно в 24 запроса.

Очень плотная неделя ещё может дать дорогой запрос. И это история оставшихся звёзд: снятые звёзды в исходной модели не сохраняются.

Баг появлялся в 0,001% случаев. Виноваты оказались два формата одного ответа

MySQL-запрос иногда возвращал пустой результат вместо строк. В Hyperdrive ошибка возникала только с включённым кешем, а поймать её трассировкой долго не удавалось.

У Cloudflare нашлось объяснение: два узла могли пользоваться общим кешем, но записывали туда разные байты. Один сохранял ответ в формате Hyperdrive, другой — уже преобразованный под возможности клиентского драйвера.

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

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

«Повторим запрос один раз» может превратиться в восемь запросов

Представьте цепочку A → B → C → D. Если D ошибается, а каждый предыдущий сервис повторяет вызов один раз, до D в худшем случае дойдут восемь попыток на один исходный запрос.

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

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

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

Закрыл тело HTTP-ответа — и неожиданно ускорил следующие запросы

В примере из блога Go программа сто раз получает HTTP-статус, не читая тело. С HTTP/1 на машине автора это занимает около 710 мс в Go 1.26 и 150 мс в Go 1.27.

Причина — повторное использование соединений. В HTTP/1 нужно дочитать текущий ответ, чтобы найти начало следующего. Раньше закрытие непрочитанного тела приводило к потере соединения для повторного использования.

В Go 1.27 net/http.Transport пробует дочитать остаток в фоне: не больше 256 КБ и 50 мс. Если успевает, соединение можно вернуть в пул. Приложению по-прежнему нужно вызвать resp.Body.Close().

Ускорение зависит от размера ответа и сети. Для HTTP/2 такая процедура дочитывания не нужна: там запросы используют отдельные потоки.

Почему разработчики Rust всё ещё выбирают print

Команда Rust опросила больше 2300 человек об отладке. Более 46% участников сейчас пользуются дебаггером. При этом логи, печать и dbg! остаются привычными инструментами.

Самая частая причина отказаться от дебаггера в конкретной ситуации — через вывод разобраться быстрее или проще. Её указали чуть больше 81% ответивших на этот вопрос.

Есть и проблемы инструментов: значения показываются неудобно, переменные не удаётся вывести, пошаговое выполнение спотыкается об async и макросы. Вместо содержимого HashMap можно получить устройство её внутренностей.

Среди направлений улучшения — визуализация типов и коллекций, async-стеки и документация по настройке. Это ответы участников добровольного опроса, а не перепись всех Rust-разработчиков.