Проектирование веб-краулера. Как решать System Design?

Привет! Продолжаю разбирать классические задачи с System Design интервью на стримах (за анонсами можете следить тут https://t.me/siliconchannel ), а это текстовая версия стрима. В прошлый раз была бесконечная лента, сегодня очередная классика жанра - веб-краулер. Условие звучит примерно так:

https://habr.com/ru/articles/1049912/

#system_design #сис_диз #Собеседование #Проектирование #highload #задачи #задачи_для_собеседований #middle #senior #web_crawler

Проектирование веб-краулера. Как решать System Design?

Привет! Продолжаю разбирать классические задачи с System Design интервью на стримах (за анонсами можете следить тут ), а это текстовая версия стрима. В прошлый раз была бесконечная лента, сегодня очередная классика жанра - веб-краулер. Условие звучит примерно так:

https://habr.com/ru/articles/1049912/

#system_design #сис_диз #Собеседование #Проектирование #highload #задачи #задачи_для_собеседований #middle #senior #web_crawler

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

Каждый раз, когда в компании возникают проблемы с производительностью PostgreSQL, обсуждение обычно идет по одному и тому же сценарию. Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные. Недавно мы в Tarantool столкнулись именно с такой ситуацией у одного из клиентов. В этой статье расскажем подробно об этой ситуации, поделимся, как мы ее решили и почему такой подход в целом стоит использовать практически всем, кто имеет дело с PostgreSQL.

https://habr.com/ru/companies/vktech/articles/1048164/

#postgresql #производительность #масштабирование #tarantool #cdc #витрина_данных #архитектура #highload #чтение_против_записи #vk_tech

# pg-smart-search: Путь от 8 секунд до 40 мс — Часть 2. Масштабирование до миллиона строк и производственная архитектура

Привет, Хабр! В первой части мы разобрали архитектуру pg-smart-search изнутри: параллельный Promise.race , механизм Zombie Prevention через AbortSignal , адаптерный паттерн и CLI-инструмент. Если не читали -- рекомендую начать оттуда, здесь я буду отсылать к тем концепциям. В этой части речь пойдет о том, что происходит, когда ты запускаешь всё это на реальных данных. На объемах до 100K строк система работала именно так, как задумано: FTS побеждал в Promise.race первым, кэш давал sub-1ms на горячих запросах, пропускная способность — 90 req/sec. Картина мечты. Потом пришли данные. Много данных. 1 000 000 строк с нормальным, реальным словарем — и всё сломалось. Время поиска улетело к 8-ми секундам. В этой статье - честный разбор двух этапов спасения: сначала архитектурные фиксы, потом бой с «ошибками выжившего» в бенчмарках. И в конце — production-grade микрооптимизации, которые мы сделали в v1.4.1, вылизав каждую миллисекунду.

https://habr.com/ru/articles/1048024/

#postgres #nodejs #typescript #gist #opensourse #highload #backend

[Перевод] System Design: проектируем Rate Limiter, ограничитель запросов

В задаче проектирования Rate Limiter важны сразу несколько вещей: выбор алгоритма лимитирования, централизованное хранение состояния, работа через API Gateway и масштабирование до 1 млн запросов в секунду. В статье разберём, почему для такого сценария часто выбирают Token Bucket, как использовать Redis для хранения счётчиков и что делать, когда одного инстанса уже недостаточно.

https://habr.com/ru/articles/1044528/

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи

Dead Letter Queue в Kafka на практике

DLQ — это просто топик. Сложное — всё, что вокруг него. Эта статья — про практическую архитектуру обработки событий из Kafka с отправкой данных во внешний REST API. Главная проблема такого сценария — нестабильность внешнего API. Он периодически деградирует по latency или начинает отвечать с ошибками, и это напрямую влияет на пропускную способность всего консьюмера.

https://habr.com/ru/articles/1045324/

#kafka #concurrency #asyncio #semaphore #finite_state_machine #dead_letter_queue #highload #api

2 + 2 = 6 и как мы это фиксим: lost updates в Postgres

Каждый бэкенд-разработчик, который хоть раз готовился к собеседованию, слышал про аббревиатуру ACID. Какая-то часть из слышавших сможет её расшифровать. Какая-то часть из расшифровавших — объяснить, почему важен каждый из принципов, скрытых за этими четырьмя буквами. И уж точно каждый из этих замечательных разработчиков знает цену букве «I» — isolation, изоляции транзакций. Те, кого заинтересовал заголовок, скорее всего, относятся к одной из трех категорий читателей: Первые знакомы с этими понятиями в теории, но не имели шанса решать их на практике. Вам — обещание: когда вы столкнётесь с этими загадочными на первый взгляд явлениями в бою, вы уже будете к ним готовы. А если прочитаете статью до конца и вникнете во все примеры — сможете блеснуть на собеседовании знанием тонкостей борьбы с гонками в реальных highload-приложениях, даже не имея такой практики. Вторые решали такие проблемы «на ощупь», не до конца понимая механику. Вам — собрать разрозненный опыт в систему: увидеть полную карту способов и понять, какой из них и почему обходится дороже. Третьи сталкивались с этими проблемами и знают, как их решать. Вам — наглядная демонстрация цены тех решений, которые вам уже приходилось имплементировать: конкретные цифры, во сколько на самом деле обходится каждый подход. В этом материале систематизируем способы бороться с race conditions в Postgres и считаем, во сколько обходится каждый.

https://habr.com/ru/articles/1044190/

#postgresql #postgres #race_conditions #isolation_levels #продакшен #highload

Динамические квоты и лимиты: как не завалить очередь в highload

Представьте: ваш сервис Y генерирует 10 000 событий в секунду, а сервис X может проглотить только 500. И при этом нельзя потерять ни одного события, а порядок обработки обязан быть строгим. Очередь? Конечно. Но какую? И что делать, когда она переполнится? В статье — разбираем реальную архитектурную задачу с разбором типовых ошибок, двух подходов к порядку (strict FIFO и per‑key ordering), нюансами DLQ, backpressure, идемпотентностью и скрытыми проблемами типа head‑of‑line blocking. Разобрать задачу

https://habr.com/ru/companies/otus/articles/1031282/

#highload #очереди_сообщений #kafka #backpressure #динамические_квоты #системный_анализ #архитектура_highload

Реальный time series агрегатор: как обрабатывать 10 событий/сек на графе из 300k узлов

Представьте, что у вас есть многослойный пайплайн обработки данных. Ширина слоя — 5000 узлов. Количество слоёв — 60. Общее число узлов — 300 000. Каждую секунду приходит 10 новых событий (изменений на входе). Наивный подход — пересчитать всё с нуля — будет перебирать все 300 000 узлов на каждое обновление. При 10 обновлениях в секунду это 3 млн вычислений узлов в секунду. А если ширина слоя 100 000 и слоёв 100? Получаем 10 млн узлов на пересчёт. Компьютер не справляется.

https://habr.com/ru/articles/1040918/

#NET #C# #Highload #аналитика #стриминг

Архитектура AI-сервисов: почему монолит убивает latency и GPU

Ваш AI‑чат или автокомплит тормозит при 50 запросах в секунду? Монолит убивает GPU и латенси? В этом туториале — реальная архитектура low‑latency инференса на high‑load: почему изолированный inference‑bundle вместо монолита, как выбрать между vLLM и SGLang без маркетинга, зачем нужны continuous batching и admission control. Читать разбор

https://habr.com/ru/companies/otus/articles/1031286/

#AIсервисы #LLM #инференс #highload #latency #GPU #vLLM #SGLang #continuous_batching #admission_control