Rate limiting и throttling: защита системы от перегрузки
Как ограничивать нагрузку: token bucket, leaky bucket, sliding window, распределённый rate limiting и чем throttling отличается от отказа
Как ограничивать нагрузку: token bucket, leaky bucket, sliding window, распределённый rate limiting и чем throttling отличается от отказа
Юнит-тесты не поймают то, что ломается между сервисами: несовместимый контракт, потерянное сообщение, гонку в eventual consistency. Как выстроить уровни для распределённой системы — юнит → интеграция (Testcontainers) → контрактные тесты (вместо хрупких e2e) → немного e2e, где тест-дубли ставить на границах, и как тестировать асинхронность и eventual так, чтобы тесты не были флаки. Стратегия, а не набор фреймворков
Одна дисциплина — пирамида тестов, дублёры, property-based и реальные зависимости через Testcontainers — в Go, Java и Python на одном домене. Что идиоматично, чем различаются экосистемы и почему на настройках по умолчанию property-тест находит реальный дефект ненадёжно во всех трёх сразу
Перегрузка — это не одна проблема и не один механизм. Лимит частоты, backpressure, сброс нагрузки, предохранители, автоскейл и наблюдаемость решают разные части задачи и стоят на разных рубежах. Карта показывает, что за что отвечает, в каком порядке срабатывает и куда идти за деталями
Девять изменений схемы через Avro, Protobuf и JSON Schema в двух направлениях, и три исхода вместо двух: прочиталось, отказ и — самый дорогой — прочиталось неверно. Одно изменение дало три разных операционных ответа: два декодера и реестр схем
Сколько на самом деле стоит бинарный формат: вес записи, вес схемы и что остаётся от разницы под сжатием. Плюс проверка того, что нужно иметь на руках, чтобы данные вообще прочитались — и почему у контрольного плеча этот вес равен нулю
Flaky-тест не «случайный» — у каждого мигания детерминированная причина: гонка, время, порядок выполнения, обход map, sleep вместо синхронизации. Разбираем пять классов на живом Go-стенде с реальной частотой мигания и настоящим детектором гонок, чиним каждый детерминизмом — а не ретраями
Как одна задача — сгенерировать UUIDv7/ULID/Snowflake — решается в Go, Java и Rust (и почему ops/sec между языками сравнивать нельзя), как типы колонок PostgreSQL (uuid/bytea/text) обходятся с этими значениями и как ::text-каст ломает индекс, и как согласовать идентификатор с ключом шардирования, чтобы монотонный ключ не устроил горячий узел.
Концепция саги проста, а прод — нет: компенсация это не rollback, а обратное семантическое действие, и её порядок, идемпотентность и «а если компенсация упала» решают, работает система или разваливается. Плюс изоляция: сага даёт ACD, не ACID — грязные чтения и потерянные обновления реальны, и с ними борются семантическими локами и контрмерами. Разбираем классификацию шагов (compensatable/pivot/retriable), персистентность саги, tooling (Temporal/Camunda/Axon) и тестирование с инъекцией отказов
Разделить чтение и запись — идея на слайде. На проде всё в проекциях: как строить read-модели, как жить с их отставанием (read-your-writes ломается), как пересобирать проекцию без даунтайма (blue-green, чекпоинты, идемпотентное применение) и когда CQRS оправдан без Event Sourcing, а когда тащит его за собой. Разбираем sync vs async проекции, несколько read-моделей на запрос, tooling (Axon/EventStoreDB/Marten) и типовую ошибку — CQRS поверх обычного CRUD