Представь, что ты делаешь новостной агрегатор (типа Google News). Одна из самых больших проблем, с которой ты столкнешься, это дедупликация статей среди миллионов документов. Наивные сравнения O(n^2) тебя просто раздавят на масштабе. А реальное решение это MinHash + LSH.

MinHash превращает большое множество в маленькую, фиксированного размера сигнатуру так, что похожесть двух сигнатур приближенно соответствует жаккаровскому сходству (Jaccard similarity) исходных множеств. Jaccard similarity это просто пересечение множеств, деленное на их объединение; мера того, насколько сильно множества перекрываются.

Это быстрый вероятностный способ оценить “насколько эти два документа похожи”, не сравнивая их слово в слово.

Первый шаг это шинглинг: ты разбиваешь каждый документ на перекрывающиеся n-граммы (например, последовательности из 3 слов), а потом запускаешь MinHash на множестве этих шинглов. На выходе MinHash дает компактную сигнатуру, обычно 100-200 хеш-значений.

Ключевое свойство такое: вероятность того, что две сигнатуры разделят одно и то же минимальное хеш-значение, равна Jaccard similarity их исходных множеств шинглов. Так ты оцениваешь сходство, вообще не трогая сырой текст.

Но проблема сравнения все равно остается. Даже с компактными сигнатурами сравнивать каждую пару дорого. Тут и появляется LSH

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

Такой подход схлопывает миллиарды сравнений до миллионов, и именно так системы вроде Google News и ранние веб-краулеры дедупили контент на больших объемах. В нескольких гугловых статьях и инженерных блогах начала 2000-х прямо упоминается этот подход. Довольно просто и аккуратно.

И как почти всегда на масштабе: тебе не нужна идеальная система детекта похожести. Нужна быстрая и достаточно хорошая, потому что стоимость в итоге и диктует правила игры.

👉 @BackendPortal

Ускорь JSON-ответы FastAPI в 2 раза, а то и больше

1. Обновись до вышедшего FastAPI 0.131.0
2. Объявляй response model (тип возврата)

После этого @pydantic будет заниматься JSON-сериализацией на стороне Rust 🦀

https://fastapi.tiangolo.com/advanced/custom-response/#json-performance

👉 @BackendPortal

Сколько бы блогов, книг или статей ты ни прочитал, прототипирование все равно остается самым быстрым способом что-то понять. Вот мой воркфлоу:

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

Ключевой момент тут это найти минимально необходимое, самый-самый минимум кода, который поможет тебе собрать нужное понимание. Сначала ты почти всегда будешь писать больше, чем нужно, но со временем начнешь подставлять данные, добавлять sleep, мокать и делать правильные допущения.

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

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

👉 @BackendPortal

Большинство думают, что каждый .sort() работает одинаково во всех языках.

Это не так.

Разные языки, разные алгоритмы:

> C++ → Introsort
> std::sort() = Quicksort + Heapsort + Insertion

> Python → Timsort
> list.sort() = Stable (стабильная сортировка)

> Java → Зависит от типа
> Arrays.sort(Object[]) = Timsort (стабильная)
> Arrays.sort(int[]) = Dual-Pivot Quicksort

> JavaScript → Зависит от движка
> Chrome V8 = гибрид в стиле Timsort
> Firefox = гибрид Merge Sort

> C → Нет фиксированной гарантии
> qsort() обычно Quicksort

> Go → PDQSort + Insertion

> Rust → Выбираешь сам
> .sort() = стабильная Merge Sort
> .sort_unstable() = PDQSort

> Swift → Интроспективный гибрид
> Ближе к PDQSort + Insertion

Один и тот же .sort(), но в каждом языке за ним могут стоять разные алгоритмы.

👉 @BackendPortal

Если ты учишь backend в 2026, прокачай вот эти 8 тем:

1️⃣Дизайн REST API
↓
2️⃣Аутентификация (JWT / OAuth)
↓
3️⃣Индексы в базе данных
↓
4️⃣Кэширование (Redis)
↓
5️⃣Rate limiting
↓
6️⃣Логирование и мониторинг
↓
7️⃣База по Docker
↓
8️⃣Основы system design

👉 @BackendPortal

Что такое LGTM?

L – Loki
структурированные, поисковые, коррелируемые логи.

G – Grafana
визуализация всего, что происходит в системе.

T – Tempo
распределенный трейсинг между сервисами.

M – Mimir
истина про поведение системы в виде таймсерий.

Вместе они отвечают на три ключевых вопроса:

что произошло? → логи
насколько все плохо? → метрики
где конкретно тормозит? → трейсы

Без LGTM дебаг распределенных систем это гадание на кофейной гуще. ❤️

Плейлист-курс по LGTM (Loki + Grafana + Tempo + Mimir)

👉 @BackendPortal

Ваша база PostgreSQL уперлась в потолок.

Текущие метрики:

- База 2 ТБ на db.r5.4xlarge
- 85% read, 15% write
- Лаг read-replica: в среднем 200 мс, пики до 2 секунд
- Количество подключений в пик упирается в максимум (500)
- Самые медленные запросы: сложные JOIN’ы по 4 таблицам с 100M+ строк
- VACUUM не успевает, растет число мертвых кортежей (dead tuples)
- Хранилище растет на 50 ГБ/месяц

Команда спорит, что делать:

- Добавить PgBouncer для пуллинга соединений
- Внедрить read-replica + роутинг запросов
- Шардировать базу
- Вынести горячие таблицы в DynamoDB
- Залить деньгами (апгрейд до db.r5.12xlarge)

В этом квартале можно выбрать только 2.

Какие 2 и в каком порядке?

👉 @BackendPortal

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

https://www.datacamp.com/blog/acid-transactions

👉 @BackendPortal

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

1️⃣for (i = 0; i < n; i++) → O(n)

2️⃣Два вложенных цикла (n × n) → O(n²)

3️⃣for (j = 0; j < i; j++) внутри внешнего цикла → O(n²)
(потому что суммарно 1 + 2 + ... + (n-1))

4️⃣i = i * 2 пока i < n → O(log n)

5️⃣i = i / 2 пока i > 1 → O(log n)

6️⃣Два раздельных цикла по n → O(n)
(в Big-O константы отбрасываем: O(n) + O(n) = O(n))

7️⃣while (n > 0) n /= 2 → O(log n)

8️⃣T(n) = T(n-1) + O(1) → O(n)

9️⃣T(n) = 2T(n/2) + O(n) → O(n log n)
(типичный merge sort)

1️⃣0️⃣T(n) = T(n-1) + T(n-2) → O(2ⁿ)
(наивная рекурсия Фибоначчи, без мемоизации)

Если умеешь сходу маппить “паттерн → сложность”, вопросы про time complexity на интервью перестают быть проблемой.

👉 @BackendPortal

p50, p95 и p99.

Сколько тут этих p и что они значат?

Коротко: p = percentile (процентиль).
Он показывает распределение производительности, а не среднее значение.

Сколько вообще бывает этих p?
Процентили есть от p0 до p100, но на практике обычно смотрят на:

• p50 -> медиана
• p90 -> первые “подтупливания”
• p95 -> базовая линия для SLA
• p99 -> tail latency (хвостовая задержка)
• p99.9 -> системы с ультра-надежностью (Google и Amazon следят за p99.9)

Представь 100 пользователей, которые бьют в твой API.

p50 = 120ms -> 50 пользователей уложились в 120ms или быстрее, 50 были медленнее.
p95 = 800ms -> 95 пользователей уложились в 800ms или быстрее, 5 были медленнее.
p99 = 2.5s -> 99 пользователей уложились в 2.5s или быстрее, 1 был медленнее (вот тут и живет фрустрация).

Почему трекать процентили, а не среднее?
Потому что средняя задержка умеет прятать боль.

Пример:

100ms
110ms
120ms
130ms
5000ms

Среднее ≈ 1,092ms ❌
p50 = 120ms
p95 = 5000ms ✅

Зная p50, p95 и p99, ты можешь:

• заметить всплески задержек до того, как все упадет
• понять реальный UX пользователей
• найти проблемы со скейлингом и контеншеном
• безопаснее настроить ретраи, таймауты и backpressure
• задать адекватные SLA
• не допустить системы “быстро, но ненадежно”

👉 @BackendPortal

Как работают куки и сессии на примере аутентификации

👉 @BackendPortal

Есть очень интересный подход к хешированию, называется Robin Hood Hashing. Это как раз из тех идей, которые одновременно простые и элегантные. Смотри.

В обычных хеш-таблицах с open addressing, когда случается коллизия, ты просто идёшь дальше по слотам, пока не найдёшь пустой. Проблема в том, что одни ключи оказываются почти рядом со своей “идеальной” позицией, а другим не везёт и их уносит далеко.

Из-за этого у неудачливых ключей получаются длинные probe-sequence, и поиск начинает заметно проседать.

Robin Hood Hashing чинит это минимальным изменением стратегии вставки. Когда вставляешь новый ключ, ты сравниваешь, насколько он далеко от своей “домашней” позиции, с тем ключом, который сейчас занимает слот. Если новый ключ “беднее” (то есть он уже дальше от своего идеала), он забирает место, а вытесненный ключ продолжает пробинг дальше.

По сути, ты “крадёшь у богатых” (у ключей, которые уютно сидят рядом с домом) и “отдаёшь бедным” (тем, кого утащило далеко). Отсюда и название Robin Hood.

В итоге дисперсия длины пробинга по всем ключам остаётся очень маленькой. Никого не оставляют сильно “позади”.

Этот алгоритм можно встретить в стандартной реализации HashMap в Rust, в нескольких высокопроизводительных индексах баз данных и в системах управления памятью, где важна cache efficiency. Он ещё популярен в хеш-таблицах, где нужна предсказуемая скорость поиска, а не просто хороший средний случай.

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

Забавно, что одно маленькое правило на этапе вставки так сильно влияет на общую производительность хеш-таблицы.

👉 @BackendPortal

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

Я тут общался с одним инженерным лидом, и по ощущениям многие уже готовятся к полностью agentic SDLC. В репозиториях начинают появляться файлы под Claude и прочие agent-штуки, под внутренние инструменты пилят MCP, и в целом многое меняется. Код-ревью тоже автоматизируют, и это только один из пунктов.

Вот такие времена :)

👉 @BackendPortal

Ограничение скорости за 40 секунд

👉 @BackendPortal

Любая база данных делает компромиссы по производительности.

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

Самые частые:

Time / Space
Делаем базу быстрее, расплачиваясь памятью или диском. Храним одни и те же данные в нескольких форматах, заранее считаем агрегаты, используем сжатие и т.д. Классический CS tradeoff.

Durability
Улучшаем latency, ослабляя долговечность. Вы делаете fsync сразу или позже? Что для вас durability: 1, 2 или N копий на диске? Нужны копии между несколькими DC?

Read / Write
Типичный пример: B-tree обычно лучше для чтения, LSM лучше для записи. Можно ухудшить чтения ради более высокой пропускной способности на запись.

Startup time
Меняем время ответа на запросы на время старта. Например, делаем индексы непостоянными (non-persistent): при каждом рестарте их нужно пересобирать, зато записи не обязаны явно обновлять индексы на диске.

Consistency
Если eventual consistency ок, это упрощает и ускоряет выполнение запросов. Strong consistency требует больше локов и блокировок.

Нужно заранее понимать свои требования по всем пунктам и выбирать DBMS под них.

👉 @BackendPortal

Видел интересное видео от CTO Zerodha про то, как они масштабировали Postgres с 7+ млн таблиц.
Технология просто выносит мозг, а если копнуть глубже, становится еще веселее:

- синхронщина? не масштабируется, значит выкидываем.
- все в async. тяжелую генерацию отчетов ставим в очередь.
- независимый middleware, которому все равно на базу и на приложение.
- собрали “DungBeetle” на Go: обобщенные, независимые от СУБД HTTP API, чтобы тянуть отчеты из любой базы.
- результаты сливаем в отдельную Results DB, а приложение читает уже оттуда.

Вот так выглядит настоящий масштаб.

Смотреть видео

👉 @BackendPortal

Хочешь посмотреть, как Java эволюционировала, фича за фичей?

brunoborges сделал офигенный сайт, где изменения языка Java показаны рядом, в формате side-by-side. Идеально для студентов и для тех, кто модернизирует легаси-приложения.

Зацени:
https://javaevolved.github.io

👉 @BackendPortal

Повышения это про проактивность, а не реакцию постфактум.

Важно, чтобы твою работу и влияние замечали, и чтобы тебя награждали за вклад. Но как этого добиться?

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

Дальше два варианта: либо менеджер скажет, что ты готов, либо скажет, что пока нет. Если готов, отлично. Работайте вместе с менеджером, чтобы оформить пакет на повышение и убедиться, что все сходится под ближайший цикл.

Если пока не готов, вместе с менеджером составьте понятный, выполнимый план. Он может занять от пары кварталов до нескольких лет, и это ок. Относись к нему как к чеклисту. Закроешь пункты, заходи с этим кейсом снова.

И если ты сделал все, что просили, но тебе все равно говорят "пока нет", то возможные пути такие:

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

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

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

👉 @BackendPortal

Продвинутые паттерны конкурентности в Go:
Bridge Channel

bridge разворачивает канал каналов в один выходной канал. Он читает каждый внутренний канал по порядку и форвардит значения в выходной.

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

В основном это отлично подходит для пагинированных или батчевых продьюсеров.

👉 @BackendPortal

Один умный человек, написал эссе про алгоритм BM25, который лежит в основе Elasticsearch, Apache Solr и Apache Lucene.

Зачем? Просто потому что ему было нечем заняться, он нырнул в кроличью нору информационного поиска: пытался понять, почему и где TF-IDF в итоге упирается в свои пределы, как на самом деле устроен BM25 под капотом, и почему системы вроде Elasticsearch, Solr и Lucene сделали его своей дефолтной функцией ранжирования.

В эссе узнаете, почему BM25 так хорошо работает, как каждая часть формулы влияет на ранжирование, и какое место он занимает в современном retrieval-стеке.

Этот текст должен дать тебе нормальную ментальную модель, чтобы понимать BM25 и также IDF из популярного TF-IDF. Зацени.

👉 @BackendPortal

Лучшая тулза для создания софтверных диаграмм.
И вдобавок бесплатная и с поддержкой GitHub

Идеально подходит для UML, флоу и процессов.
Экспортирует в картинку, PDF, HTML и другое.

→ http://app.diagrams.net

👉 @BackendPortal