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

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

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

Имеется:
- Сервера ДБ_А(Москва), ДБ_Б(Питер)
- Сервера приложений АП_А(Москва), АП_Б(Питер)
- web-сервера в количестве

После успешного запуска проекта планируется расширение сети на все города РФ.
Среднесрочный план предполагает захват рынков пиццы США, Японии и Папуа Новой Гвинеи.
Долгосрочная цель - охватить услугами колонии на Марсе, Венере и Альдебаране.

Сущности:
- Клиент (геопривязка, фио, баланс, бонусы, кем_приведен, индекс лояльности)
- Услуга (геопривязка, наименование, цена)
- Заказ (клиент, услуга, количество, сумма, начисленные бонусы)


Принято решение делить клиенскую базу и базу заказов по территориальному признаку.
(Не согласны? Предложите иной вариант)

Требуется:
1. Предложить схему предоставления услуги "продажа пиццы" для случая, когда клиент_А (Москва) пытается получить услугу_Б (Питер).
2. Предложить схему реализации маркетинговой кампании "приведи друга" для случая, когда клиент_А приводит клиента_Б. По условиям компании клиент_А должен получать бонусы с каждой продажи клиенту_Б в течение года.

Схема предоставления услуги должна включать:
- рекомендации (if any) по разделению данных сущностей Клиент, Услуга, Заказ по Независимым Изолированным Серверам.
- схему взаимодействия серверов приложений и серверов БД
- схему движение данных (у кого что спрашиваем, куда что дублируем)

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

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

Очень хорошо, поехали.
Как данные о заказах и начисленных в Питере бонусах попадают на московские сервера?
Как московскому гостю начисляются бонусы за продажи Питерскому другу?
А за продажи Питерскому другу, сделанные в Москве?

не мудриобычно вообще никак (ибо нефиг), а если ну очень сильно надо - то через soap какой (все помнят рекламный ролик про java)
в soap даже email как транспорт числится, фигли

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