Я попробовал восстановить так, как это было на самом собесе, ничего не добавляя постафктум. Решение не может отличается от того, как сделали бы вы, это нормально.

Задача была поставлена следующим образом (с учётом собранных мною требований):

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

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

1. Order API — по order_id возвращает данные по заказу, в т.ч. и courier_id. Среднее время ответа — 1 секунда.
2. Courier API — по courier_id возвращает текущие координаты. Среднее время ответа — ещё 1 секунда.

Наш сервис должен принимать запрос от клиентского приложения вида

GET /orders/{order_id}/location

и отвечать координатами курьера: широта и долгота.

Жёсткое требование:

время ответа сервиса не должно превышать 300 мс,

даже при высокой нагрузке и географически распределённой системе.

Дополнительные условия:

- Мы не знаем список заказов заранее — о заказе узнаём, когда клиент впервые запрашивает его позицию.

- Внешние API трогать или ускорять нельзя.

- Сервис должен быть масштабируемым, отказоустойчивым и геораспределённым. 🐱

То есть нам нужно уложиться в SLA 0.3 секунды, хотя единственное место, где есть нужные данные, отвечает ~2 секунды. 😨

Как это сделать? Чистая архитектура, никаких костылей.

Чтобы уложиться в SLA по времени отклика и при этом не зависеть от скорости внешних API, система строится вокруг нескольких ключевых принципов:

1️⃣ Асинхронное наполнение данных (warm-up).

Первый запрос по заказу не вызывает цепочку из двух медленных API. Вместо этого сервис мгновенно возвращает location = null, а фоновый воркер начинает процесс получения данных:

• обращается к Order API, чтобы получить courier_id;
• по этому courier_id запрашивает координаты в Courier API;
• сохраняет результат в Cassandra.

После этого все последующие запросы по данному заказу читают данные напрямую из базы.

2️⃣ Хранение в Cassandra без промежуточных кэшей.

Сервис не использует локальные in-memory или Redis-кэши. Все данные хранятся централизованно в Apache Cassandra, которая обеспечивает:

• быструю запись (до десятков тысяч upsert-ов в секунду на ноду),
• горизонтальное масштабирование без единой точки отказа,
• репликацию между регионами.

Используется стратегия NetworkTopologyStrategy с ReplicationFactor = 3 на каждый регион и уровень согласованности LOCAL_QUORUM — это позволяет читать и писать данные локально, не дожидаясь удалённых DC.

Почему Cassandra, а не Redis?

При выборе хранилища ключевым фактором стали характер нагрузки и требования к надёжности.

• Профиль нагрузки — write-heavy
  Каждый активный курьер обновляет координаты каждые 2–5 секунд. При десятках тысяч активных курьеров это десятки тысяч UPSERT-операций в секунду.
  Такая нагрузка типична не для кэш-систем, а для постоянных write-heavy хранилищ, оптимизированных под линейное масштабирование и дешёвые вставки.
• Геораспределённость и отказоустойчивость
  Redis, даже в кластерном режиме, не предоставляет аналогичной модели актив-актив без внешней прослойки (обычно нужен либо CRDT-слой, либо дорогая мульти-мастер-репликация).
• Консистентность и долговечность
  Для геопозиции допустима eventual consistency, но при этом важно, чтобы данные не терялись.

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

Redis, напротив, ориентирован на скорость чтения и простоту, а не на долговечность — потеря узла или выключение snapshot-механизма может привести к частичной потере данных.

3️⃣ Разделение API и воркеров

• API-слой отвечает только за быстрые запросы клиента и формирование ответов (200 OK с координатами или warmingUp:true).
• Воркеры асинхронно взаимодействуют с внешними сервисами, обновляют данные в Cassandra и управляют фоновыми циклами обновления координат курьеров.

Один воркер может обслуживать сотни активных курьеров, выполняя обновления каждые 2–5 секунд.

4️⃣ Схема хранения данных.

Используются две основные таблицы:

CREATE TABLE order_to_courier (
  order_id  text PRIMARY KEY,
  courier_id  text,
  assigned_ts timestamp
);
  
CREATE TABLE courier_location_current (
  courier_id  text PRIMARY KEY,
  lat double,
  lon double,
  provider_ts timestamp,
  updated_ts  timestamp
);

order_to_courier заполняется один раз на заказ, courier_location_current обновляется каждые несколько секунд.

Поведение системы

1️⃣ Клиент делает запрос GET /orders/{orderId}/location.

Сервис обращается к Cassandra:

• если данные есть — возвращает координаты;
• если нет — отдаёт null и ставит задачу в очередь.

2️⃣ Воркеры обрабатывают очередь:

• получают courier_id и координаты;
• обновляют таблицы order_to_courier и courier_location_current.

3️⃣ Следующие запросы обслуживаются из Cassandra — без дополнительных внешних вызовов.

Что бы вы сделали иначе?

⸻

Давайте оставаться на связи - https://t.me/ask_for_oleg ☄️

Всем привет. Сегодня пусть будет не про архитектуру. Точнее, и про архитектуру, но не ту.

Год назад мы с семьёй переехали в свою квартиру. Получился ещё тот квест, но это совсем другая история. Обустраиваемся тут, заканчиваем ремонт. Мне, как удалёнщику со стажем, важно сделать себе рабочее место и провести интернет хорошего качества. В принципе, первое, что появилось в доме, - это роутер. Причём это Huawei от Ростелекома. Не совсем отвратный, но и не топ. Причина появления именно такого роутера в том, что подключение происходит по оптике, а не витой паре. Мой прежний роутер такое не умел. В целом интернет работал, скорость была нормальная, всё в порядке. Так я думал, пока мы окончательно не перебрались домой. Не знаю, из чего у нас сделаны стены, но сигнал роутера нормального качества есть только в прихожей, где он и находится. Ну или в зоне прямой видимости. В других комнатах качество сигнала сильно деградирует.

Я скачал тулзу для измерения уровня сигнала и походил по комнатам. В спальне уровень сигнала 30%, на рабочем месте - всего 20%. При этом если смещаюсь на 30 сантиметров назад и встаю напротив двери, откуда роутер почти видно, сигнал уже 85%. То есть до рабочего места сигналу надо преодолеть 5 стен, и это его почти полностью гасит. В старой квартире ситуация была почти такой же (по препятствиям), но там сигнал и качество деградировали не так сильно (по субъективной оценке, я тогда не замерял).

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

Попытка 1

Решил подойти к проблеме в лоб. Достал свой старый роутер (ASUS RT-AC68U), связал его с Huawei как ретранслятор. Asus разместил рядом с рабочим местом, назначил ему такой же SSID с постфиксом rep. Ожидаемо, качество сигнала стало отличным -роутер же рядом. Но вот интернет остался плохим. Asus мог работать как ретранслятор только в диапазоне 2,4 ГГц. К тому же у него мощнее покрытие, из-за чего сеть не терялась даже в ближайшей к Huawei комнате. Получалось комбо: сильный сигнал и слабый интернет. Так прошёл ещё месяц, после чего я перешёл к следующей итерации.

Попытка 2

Раз у Asus лучше покрытие, значит можно поставить его в удачное место и наслаждаться связью, которая ловит даже на парковке. Я соединил оба роутера витой парой, настроил у Asus SSID, а у Huawei вообще выключил Wi-Fi, чтобы не создавать интерференцию. Качество сигнала на рабочем месте поднялось до 30% - уже лучше. Но 5 ГГц деградировал до 2,4 ГГц и не выдавал больше 15 Мб/сек. В целом стало лучше, чем было, но на созвонах и лекциях картинка всё ещё фризилась. Да и загрузка контента часто подвисала. Так прошло ещё полгода.

Попытка 3

Всё-таки дискомфорт перевесил мою лень. Я решил поискать более системное решение вопроса и сдуть пыль с диплома инженера по сетям.

Какие варианты есть у современного мира?

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

1. Powerline-адаптеры (интернет через розетку). По витой паре передаются электрические импульсы, их можно пустить и через электросеть. Но, во-первых, от топологии проводки будет зависеть, насколько деградирует сигнал, а во-вторых, у меня комнаты разделены по автоматам, и нет уверенности, что это вообще заведётся.
2. Использовать специализированный повторитель (усилитель). Я с этим мало работал, но почитал и понял, что это создаст ещё одну сеть, плюс съест скорость, и результат будет как в первой попытке.
3. Mesh-система. Это беспроводная ячеистая сеть (WMN) с бесшовным роумингом. Она может работать как по проводу, так и по воздуху. В отличие от обычных репитеров, здесь используется выделенный транспортный канал (Backhaul), чтобы отделить служебный трафик. Это позволяет сохранить производительность. При этом у меня всегда один SSID, а подключение происходит к ближайшему роутеру. Управлять всей сетью можно как единым целым из любой точки квартиры.
4. Можно было сделать два роутера с одним SSID и настроить расстояние, при котором роутер отменяет сигнал.
5. Использовать WDS. Но я почитал - слишком сложно, хотя и похоже на рабочий вариант. Всё равно будет резать скорость.

В итоге я остановился на Mesh-системе с Wireless Backhaul. Правда, мои старые роутеры меш не поддерживали, поэтому пришлось раскошелиться на лакшери Keenetic. Настройка очень простая: на ведомом роутере надо переключить тумблер режима, связать главное устройство с ведомым и всё. Дальше магия WMN на канальном и сетевом уровнях модели OSI.

В результате получилась топология:

Huawei (как адаптер PON-LAN) → Keenetic Voyager Pro KN-3510 → Keenetic Speedster KN-3013.

Итог:

один SSID для 2,4 и 5 ГГц на всех роутерах внутри сети. На рабочем месте сигнал 75% и скорость 200 Мб/сек. Потеря скорости составила ~55%. Не идеально, но лучшее из всего, что было. Из минусов - требуется перенастройка умных устройств.

Давайте оставаться на связи!

Вообще, давно хочу раскрыть такую тему как Фича-флаги (или feature flags, feature toggles). Тема хоть и старая, но актуальная и интересная. Они бывают статические, т.е. устанавливаются на этапе сборки проекта, и динамические, это когда можно менять прямо в рантайме поведение приложения.

Соответственно, реализация может быть

🧩 через конфиг (env, обычный файлик с конфигами)

🧩 через штатную базу данных проекта (обычно это реляционная СУБД)

🧩 через in-memory DB (redis, memcache etc.)

🧩 через 3d-party приложение (LaunchDarkly, Flagsmith и т.д.). В Gitlab (правда в Premium) тоже можно, кстати.

🧩 своё решение 🧠 - тут уже кто на что способен.

Соответственно, статические это быстро и дёшево, но не гибко. Нужно включить - передеплоивай приложение. Ну это ладно, это пол беды. Чтобы закатить что-то обратно - тоже нужно передеплоить. Это уже больнее.

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

🎢 Плавный rollout.

Это одно из моих самых любимых.

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

В коде можно что-то типа такого сделать

<?php

final class FeatureRollout
{
    public function __construct(
        private readonly int $percentage // 0–100
    ) {
        if ($this->percentage < 0 || $this->percentage > 100) {
            throw new InvalidArgumentException('Percentage must be between 0 and 100.');
        }
    }

    public function isFeatureEnabledFor(string $userIdentifier): bool
    {
        $hash = crc32($userIdentifier);
        $bucket = $hash % 100;

        return $bucket < $this->percentage;
    }
}

$rollout = new FeatureRollout(30); // включено для 30% пользователей

$userId = 'some-uuid';

if ($rollout->isFeatureEnabledFor($userId)) {
    echo 'Показать новую фичу';
} else {
    echo 'Оставить старое поведение';
}

тогда конфигурироваться должно и состояние флага, и процент раскатки.

По категориям

🔥 Release Toggles - позволяют интегрировать незавершённые функции в основную ветку кода, отключая их до готовности к релизу.

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

🔥 Experiment Toggles - используются для A/B-тестирования и оценки пользовательских реакций на различные варианты функциональности.

🔥 Ops Toggles - предоставляют возможность оперативного включения или отключения функций в зависимости от условий эксплуатации или производительности системы.

Ну тут всё понятно. Самый кайф.

🔥 Permissioning Toggles - ограничивают доступ к определённым функциям для конкретных групп пользователей, например, только для премиум-клиентов.

По стратегии использования

🧩 Краткосрочные - для временного использования и должны быть удалены после завершения эксперимента (расктаки).

🧩 Долгосрочные - требуют постоянного управления и документирования. Они с нами надолго.

Как обычно, у любого инструмента есть своя цена

⚠️ Сложность тестирования - yвуличие множества флагов может привести к комбинаторному взрыву вариантов для тестирования. Необходимо тщательно планировать стратегии тестирования.

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

⚠️ Если используем внешнюю систему, то нужно позаботится о кешировании флагом и об инвалидации кеша. Либо как хранить флаги поближе к коду. Ходить по http - не вариант.

-

Давайте оставаться на связи

$mutex->acquire('my-lock', 10);

Поскольку в нашем проекте мьютексы хранятся в Redis, я был уверен, что число 10 в этом контексте обозначает TTL (Time To Live) блокировки, то есть время, через которое блокировка будет автоматически снята. Это предположение основывалось на том, что в команде Redis для установки блокировки используется следующий синтаксис:

SET lock_name unique_value NX PX 5000

Здесь создаётся блокировка с именем lock_name, где "владельцем" является unique_value (снять блокировку можно только, указав это значение) на 5000 миллисекунд, если такого ключа у "владельца" нет.

Кроме того, мой опыт работы с Symfony подсказывал, что при создании мьютекса можно передать только TTL. Однако, как оказалось, в случае с Yii2 я ошибался. Изучив код, я понял, что параметр 10 в методе acquire обозначает не TTL, а таймаут — время, в течение которого процесс будет ожидать освобождения мьютекса.

Как устроены мьютексы в PHP-фреймворках?

Рассмотрим интерфейсы и их реализацию в различных фреймворках, поскольку на глубоком уровне они работают схожим образом, особенно при использовании Redis.

Yii2

if (!$mutex->acquire($mutexName)) {
    return;
}
try {
    // критическая секция
} finally {
    $mutex->release();
}

При таком использовании метод acquire сразу вернёт false, если блокировка не может быть установлена, и ожидание не произойдёт. Если вызвать $mutex->acquire($mutexName, 10), процесс будет ожидать до 10 секунд, пока мьютекс не освободится. Однако TTL также можно задать.

Yii3

В Yii3 добавлена обёртка \Yiisoft\Mutex\Synchronizer:

$synchronizer = new Synchronizer($mutexFactory);

$result = $synchronizer->execute('my-lock', function () {
    // критическая секция
}, 10); // таймаут 10 секунд

Здесь освобождение мьютекса происходит внутри Synchronizer, что удобнее и безопаснее. Это избавляет от необходимости писать собственные обёртки. Для тех, кто предпочитает полный контроль, мьютексы можно использовать так же, как в Yii2.

Laravel

В Laravel мьютексы являются частью пакета кеширования:

Cache::lock('my-critical-section', 10)->block(5, function () {
    // критическая секция
});

Здесь создаётся мьютекс с TTL 10 секунд и таймаутом 5 секунд. Освобождение происходит автоматически. Можно также выполнить всё вручную:

$lock = Cache::lock('my-task', 10);

if ($lock->get()) {
    try {
        // критическая секция
    } finally {
        $lock->release();
    }
}

Мьютексные блокировки часто применяются для предотвращения параллельного запуска фоновых задач. В Laravel существует middleware WithoutOverlapping в пакете очередей, который использует тот же мьютекс, предоставляя удобную обёртку для типовых задач.

Symfony

Symfony предоставляет, пожалуй, самый гибкий и полный пакет для работы с мьютексами:

$lock = $factory->createLock('pdf-creation', ttl: 30);
if (!$lock->acquire()) {
    return;
}
try {
    // выполнение задачи менее 30 секунд
} finally {
    $lock->release();
}

Здесь блокировка создаётся в неблокирующем режиме. Можно создать и в блокирующем, используя acquire(true). Также можно обновлять TTL мьютекса через $lock->refresh(), если становится понятно, что первоначального TTL недостаточно.

Особое внимание в этом пакете привлекают блокировки с разделением доступа. Поддержка этой функции зависит от используемого адаптера; для Redis она доступна. В то время как acquire захватывает исключительную блокировку, после которой никакой другой процесс не сможет ни читать, ни писать в защищённый ресурс, acquireRead (разделяемая блокировка) позволяет нескольким процессам захватывать блокировку в режиме чтения, пока кто-то не выполнит исключительную блокировку.

Заключение

Подобные библиотеки делают использование мьютексов простым и удобным, скрывая тонкости реализации. Например, последовательное выполнение команд GET (проверка наличия ключа) и DEL (удаление ключа) для снятия мьютекса не гарантирует атомарность операции, поскольку между выполнением этих команд значение ключа может измениться другим процессом. Поэтому требуется выполнение Lua-скрипта:

if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

Этот скрипт обеспечивает атомарность операции удаления мьютекса, проверяя значение ключа перед удалением.

Подписывайся на канал 🤘