Сейчас для PersMarket приходится много где добавлять кэш. Есть файловый кэш на бэкенде, есть на фронтенде, и есть отдельный Redis для этого дела. И вот хочу напомнить, что кэш имеет свои нюансы. Например, есть так называемая проблема грохочущего стада (Cache Stampede), это ситуация, когда протухает какой-то популярный ключ и много параллельных процессов пытаются его освежить одновременно, тем самым перегружая систему. Есть вот такие способы решения проблемы: ▪️Внешняя блокировка (Mutex Lock) - один из процессов получает право идти за обновлением, остальные заблокированы и ждут. ▪️Дедупликация запросов (Singleflight) - запросы объединяются в один, идут за обновлением, результат получают все. ▪️Стратегия Stale-While-Revalidate - кэш продолжает отдавать устаревшее (stale) значение, пока фоновый процесс ходит за обновлением. ▪️Фоновый предрасчет (Cache Warming / Background Refresh) - фоновый процесс обновляет ключи незадолго ДО их истечения. ▪️Случайный TTL (Jitter) - к времени жизни ключа (TTL) добавляется случайная погрешность (jitter), чтобы ключи с одинаковым TTL не истекали одновременно. Чаще всего эти подходы не обязательно внедрять руками. Есть уже готовые решения для всех популярных языков, например, такие: .NET, Node.js, Python, Java, PHP, Go. И не одно решение, конечно. Даже в вайбкодинге не забывайте про стадо! 🐂🐂🐂 #architecture

🥂Разбор Go 1.27 полностью дописан! Вы уже, наверно, забыли о том, что вышла новая версия языка, и что я пишу о ней статью.. 😩 В статье появились разделы про аллокации и рантайм, net/http, портируемый SIMD и go fix, а в самом конце чек-лист на случай, если после апгрейда у вас упал CI. А ещё я добавил в большинство запускаемых код-сниппетов, включая старые, переключатель версии, чтобы сравнить новое поведение с прежним (там, где это имеет смысл). Так ещё интересней щупать изменения. Если запутались в истории обновлений этого обзора, можете тыкнуть на дату обновления (в шапке статьи), там будет хронология важных правок. ---- 😩 Честно говоря, на эту статью я потратил неадекватно много времени. Релиз вышел 19 августа, а на дворе уже октябрь. Каждый раз, когда я брал в работу новый пункт из release notes, упирался в вопросу «а почему?». Например, авторы пишут, что мелкие аллокации подешевели «до 30%» на микробенчмарке и примерно на 1% в реальном коде. Откуда такой разрыв? Пришлось лезть в исходники рантайма и гонять разные бенчмарки на трёх машинах. Оказалось, что ускорение выключается, пока сборщик мусора помечает живые объекты. Чем больше программа аллоцирует, тем чаще работает сборщик и тем реже ей достаётся ускорение. А ещё мне хотелось, чтобы всё это читалось интересно и легко, даже сухие разборы бенчмарков. К примеру, я очень долго возился с графиками, пытаясь сделать их максимально понятными, наглядными и простыми. Но оно того стоило. В итоге, обзор релиза превратился в небольшой, но глубокий экскурс во внутрянку актуального Go — как аллокатор раскладывает объекты по спанам, когда запускается сборщик мусора, как были устроены таймеры до 1.23, зачем процессору векторные регистры и др. Так что, даже если сам релиз вам не особо интересен, статья — хороший повод углубить свои знания. Ну и на собеседовании про аллокатор будет что рассказать. Надеюсь, вам понравится! ———— Теперь напьюсь отдохну, и пойду дописывать обновлённую серию статей про Планировщик. Работы непочатый край.. ❤️ Если захотите поддержать мой труд, милости просим в наш закрытый клуб. Я сейчас занимаюсь контентом фуллтайм, и ничего не продаю, поэтому ваша поддержка очень важна.

Все думают UUID нельзя подобрать. Ага как бы не так 😄 /api/order/a1b2c3d4-e5f6-7890-abcd-ef1234567890 - ну как ты угадаешь? Никак. Но тебе и не надо угадывать. Вчера смотрю как QA на проекте у себя тестит (я его курирую). Открывает свой заказ. В ответе приходит: { "my_order" "a1b2c3d4...", "other_orders" [ "b2c3d4e5...", "c3d4e5f6..." ] } Бекендер для удобства отдал список всех последних заказов в том же ответе. С UUID. QA увидел и прошел мимо. "Ну это же просто список, UUID же не угадаешь". А это уже IDOR. Критический. Тебе отдали чужие UUID. Дальше просто подставляешь. Тот же баг что и с 1024 -> 1025 или 10-11. Только в 2026 так делают чаще, потому что думают UUID = защита. QA бы завел как "лишние данные в ответе" - low. AppSec заведет как "IDOR + Information Disclosure, утечка PII" - critical + премия. Бекенд не защищает UUID. Защищает проверка "твой ли это заказ". Сколько раз вы видели в ответе чужие id и не обращали внимания? Вы можете верить можете нет я такие проблемы вижу постоянно, ок не постоянно вру, но оооочеь часто Наверное не зря да IDOR на первом месте стоит?? Мораль поста! Есть UUID? Не переберешь особенно v4, v7 Но что если получить UUID где-то в другом месте? Вот и думайте

Причина перекосов в уровне балансировки L4-балансировщик выбирает серверную ноду при создании соединения. Дальше http.Transport может переиспользовать это соединение через keep-alive, из за чего может случиться перекос нагрузки на одну ноду. Проблема далеко не новая, но я хочу разобрать отдельные решения подробнее. В чем, собственно, проблема: Для http 1.x свободные соединения в http.Transport переиспользуются по LIFO: логично, что нам выгоднее взять последнее освободившееся. Это видно в реализации http.Transport.queueForIdleConn и в самой модели http.Transport:

type Transport struct {
    ///
 idleConn     map[connectMethodKey][]*persistConn // most recently used at end
    ///

В отдельных кейсах типо #79664, LIFO может приводить к перекосу: если одна из нод отвечает немного медленнее остальных, её соединение позже возвращается в idle pool и оказывается последним использованным. Следующий запрос снова забирает его, нода опять отвечает дольше — и так по кругу. В данном кейсе мы минует L4 - ведь новых соединений нет и выбирать ему просто нечего. Периодическая ротация соединений встряхнет L4 (рис 1) В вышеописаном issue предлагают добавить новый параметр, который ограничит число запросов на одно соединение (MaxRequestsPerConn), чтобы они периодически закрывались и снова проходили через балансировщик. Например, можно периодически вытеснять активно переиспользуемые соединения через вероятностное включение Request.Close. Подобную задачу давно решают на инфраструктурном уровне, например, в nginx есть upstream параметры keepalive_requests - которое ограничивает число запросов и keepalive_time типо время жизни соединения. Поэтому часть подобных проблем по 10+ лет не доезжает до http.Transport: их уже умеет решать инфра снаружи. Балансировка на уровне пулов (рис 2,3) Можно поступить грубее и держать несколько независимых http.Transport и распределяться между ними. Так устроен clbtransport: снаружи это обертка, которая внутри ротирует запрос между несколькими пулами. Перед каждым запросом сравнивается два кандидата: один по round-robin, второй рандомный. Запрос уходит в тот пул, где меньше незавершённых запросов на пул (это кстати Power of Two Choices). К тому же пулы периодически пересоздаются в фоне с jitter, чтобы минимизировать одновременное закрытие и создание кучи соединений. Но внутри каждого пула остаётся LIFO, а конкретную ноду по-прежнему выбирает L4 только при создании соединения. Кастомная балансировка на уровне отдельного RPC - на примере gRPC (рис 4) В http2 привязка к соединению становится ещё важнее: через одно соединение одновременно может идти множество стримов. Видимо поэтому в gRPC балансировку вынесли в клиент благодаря отдельным моделям: Resolver, который получает адреса доступных нод (аля service discovery), Picker - модель, которую выбирает подходящее соединение (`SubConn`) для каждого запроса. Клиент может поддерживать соединения сразу с несколькими нодами напрямую, если перед каждым запросом вызывать Picker, который выбирает подходящий SubConn по заданной стратегии - например round-robin или least-request, который тоже использует Power of Two Choices. Но в отличие от clbtransport, здесь выбор происходит уже между конкретными нодами, а не между пулами с агрегированным счётчиком активных запросов на каждый пул. Не буду пересказывать то о чем можно почитать в доке gRPC. И подробнее про реализацию кастомного grpc балансировщика На этих примерах хорошо видно, что балансировка зависит в том числе от уровня, где она вызывается. В http.Transport для http 1.x L4 участвует только при создании соединения. Пока keep-alive соединение переиспользуется, новый выбор ноды не происходит - для этого нужно открыть новое соединение. В gRPC балансировку встроили прямо в клиентскую модель: он поддерживает соединения с несколькими нодами и выбирает подходящее для каждого запроса. Нравится..

MetaORM — когда устал от ORM настолько, что написал свою 16 лет в разработке, 10 из них ежедневно с базами данных, и человек спокойно пишет, что путается в уровнях изоляции, не выучил расшифровку ACID и простой запрос с JOIN осиливает только через Гугл. За 7 лет коммерческой разработки сложный SQL-запрос не понадобился ни разу, а больше половины возможностей популярных ORM так и остались нетронутыми. Один и тот же кусок кода перекочёвывал из проекта в проект, пока не превратился в отдельный пакет. Внутри декларативные фильтры, генераторы стандартных CRUD-операций и тонкий слой транзакций через contextvars. Ни unit-of-work, ни identity map, ни ленивых прокси, ни магического отслеживания состояния объектов. Остаётся только то, с чем backend сталкивается каждый день, взять запись по идентификатору, отфильтровать список, обновить пару полей, создать сущность внутри транзакции. Посмотрим, что остаётся от ORM, когда убираешь из неё всё, чем не пользуешься.

Периодически на проектах возникает необходимость определить геолокацию пользователя по его IP. Например, узнать его страну, чтобы сменить линейку тарифов или учесть законодательство. Раньше мы пользовались базами MaxMind GeoIP. Их можно было выгрузить в виде MMDB-файлов, это такой формат, поддерживающий бинарный поиск по диапазонам IP. У них есть Lite версия, ее вполне хватало. Но сейчас, вижу, для использования нужна регистрация, а еще лучше - много денег в кассу. Еще один вариант - DB-IP, у них тоже есть Lite-версия. Причем базы можно скачать. Правда, лицензия там - Creative Commons Attribution, для использования в веб-приложениях нужно будет разместить ссылку на их сайт. Есть IP2Location, но там сразу цены конские. Можно работать с сервисами через API. Есть, скажем, IPinfo, онлайн, с бесплатным тарифом и рядом ограничений. Или вот IP-API. Отдают немало инфы. Но есть лимит в 45 запросов в минуту. И, понятно, в наше время нет гарантий трансграничной доступности сервиса. Ну а бесплатно можно скачать MMDB с вот этого сайта. Пишут, что не надо лицензий и ключей. Детализация только до уровня страны, город уже не найти. Но для многих случаев этого достаточно. Если используете что-то подобное, поделитесь. #tools

Веб-разработчики прекрасно знают HTTP-методы для взаимодействия клиента с сервером. Через GET обычно данные с сервера получают. Через POST можно создать или обновить. Удалять логично через DELETE. А вот HEAD, например, мы используем для проверки соединения, чтобы сэкономить трафик а теле запроса. Так вот, кто-то сидел и скучал о методе, который бы объединил GET и POST. Чтобы слать для запроса извлечения данных дополнительные параметры, скажем, фильтры, не в строке запроса, а в теле. Ну, типа мутант - GET-запрос с телом от POST. И придумали новый метод - QUERY. На эту тему даже сформировали отдельный RFC 10008 - The HTTP QUERY Method. То есть это как раз и получается идемпотентная операция запроса данных, аналогичная GET, но с телом POST, где вы можете слать тот же JSON с фильтрами и пагинацией. Подробности - в статье. #web

PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря В PostgreSQL уже хранятся пользователи, заказы и платежи, а потом стек начинает расти сам собой, когда рядом появляются Redis для очереди задач, отдельный Python-скрипт для дедупликации событий, Go-цикл, который считает интервалы между статусами заказа, свой поисковик вместо простого поиска по тексту и самодельная таблица locks для координации воркеров. Большая часть этой инфраструктуры дублирует то, что PostgreSQL умеет делать сам, причём атомарно, транзакционно и с индексами, без лишней сетевой болтовни между приложением и базой. Механизм, который снимает необходимость в отдельном брокере задач, живёт в PostgreSQL ещё с версии 9.5, просто про него редко вспоминают. Та же история с оконными функциями, полнотекстовым поиском и блокировками на уровне базы, где задачи, ради которых обычно поднимают отдельный сервис, часто закрываются прямо в таблице. Обсудим, сколько из этой цепочки сервисов держится просто на привычке.