>>191189
На этот вопрос нельзя осмысленно ответить не зная специфики данных, как они будут читаться, как они будут записываться и как долго будут хрнаиться, а так же какие у них будут вторичные применения.
Но если хочешь немного газированной лужи, то:
В самом общем случае всё сводится к шардированию/федерированию. От локалити-регионов до партитиций пространства ключей. Отдельную партитицию отдельной федерации можно реплецировать, реализовать как имеющий кворум локальный кластер, если даунтаймы нежелательны -- тогда при аккуратной разработке ноды в том числе можно будет по одной заменять и апдейтить.
Партитированная/кластеризованная архитектура может быть в том числе и рекурсивной, конечные k/v могут использоваться в доменно-специфично партитированном сервисе, доменно-специфичные сервисы могут представлять локальный сайт федерации, локальный сайт федерации может быть частью региональной, etc.
С точки зрения общей архитектуры всё достаточно просто и очевидно.
На уровне моделей данных, особенно в случае с запилом поиска может потребоваться паралельная инфраструктура для поддержки кешей и индексов, но тут опять же не зная специфики данных и какие n-арные индексы можно задействовать, дальше того же logn не уедешь.
Настоящие сложности начинаются с реализацией такой архитектуры на практике, тут помешать могут в первую очередь административные сложности, например меняющиеся требования - в какой-то момент продуманную и замоделенную архитектуру могут начать хотеть использовать для неподходящих ей задач. Тут по-хорошему может быть нужно тотальное переосмысление, рефакторинг и реструктурирование, а ресурсов на это может не быть. Или неверифицируемая разработка - без полноценных тестовых-пердпродовых-клонопродовых площадок, повсеместного покрытия тестами апишек-кода и прогонов на самых разных конфигурациях и наборах данных, уложить что-то в даунтайм на проде очень легко. А мотивировать штат QA/девопсов в несколько раз больше разработки может быть не всегда просто.
К сожалению практически любой, в том числе высоконагруженный проект представляет собой большой конгломерат из не всегда корректно подходящих под задачу, но всёравно используемых компонент, которые рефакторят но нормальные реализации только по очень большой необходимости. А могут и не тестировать полноценно и ловить всякие неожиданные эджкейзы. Очередь на перепроектирование может формироваться просто из сортировки по числу, северности и продолжительности ошибок/тормозов в метриках, а до тех пор затыкаться сервисмешами с горячим кешем запросов где возможно.
Как правило вместо того чтобы моделировать супербыстрые индексы под фиксированную часть датасета и мешить их на разных уровнях, полезней думать оказывается о том как быть в курсе того что тормозит и того что валится -- покрывать что можно без ущерба рантайму метриками, конечными сервисами пробрасывать трейсинг, держать девопосов которые будут за этим всем следить и делать алерты как что-то пошло деградировать, пускать канареек с частью трафика прода, в свободные интервалы симулировать ошибки -- всё что бы иметь возможность отловить и точно локализовать ошибки, как в коде, так и архитектуре.
Ну и ещё при всеобщей партитированности данных возникает вопрос их консистентности, тут может быть несколько подходов, от коорданатора(ов) до распределённых транзакций и очередей. И тут уже никакой серебряной пули быть не может, только трейдоффы. Или потеря части транзакций, или атомарности, или минимальности раундтрипов, или децентрализации, или ресурсов. В общем случае наверное координатор будет наименее оверхедным и легко масштабируемым решением -- можно обьединять группы доменов под локальным координатором например, но в зависимости от специфики данных, альтернативы могут быть удачней.
>>191211
Врядли в последние лет пять много у кого-то была возможность деплоится куда-то ещё. Если конечно не какой мастадон который с 90х свою инфрструктуру с нуля, но и те потихоньку переползают, всё же проще поддерживать фосс с кучей готовых проектов и запланированной расширяемости, а своих освободившихся девелоперов на что-то фичевое отправить. Если конечно не банк какой, они те ещё консервахи с живым миниксом и спарками. Но им и понятно что 90% оверхеда затанковать проще чем что-то менять.
>>191212
Олсо не имеющий персистенси сервис != stateless. Stateless сам по себе - это FP, очень красиво, но очень бесполезно. А как только появляются точки взаимодействия с реальным миром, то там-то всё и рушится на доступности данных.
Другое дело чтобы изолировать места где нужно вобще что-то персистить и там уже накручивать партитиции-реплики и прочее. Но как правило это достаточно самоочевидно, что какому-нибудь апи-гейтвею не нужна своя бд, а нужен допустим отдельный сервис аутентификации, который может в свою очередь иметь бд именно аутентификационных/авторизационных данных, которая в своём кластере и наборе реплик.