Накладные расходы на контекстную реализацию против избыточности

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

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

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

Итак, мои два решения таковы:

1. передавать местоположение как метаданные в запросах с каждого сервера, создавать новые расширенные схемы для базы данных, локальной для клиента, для кэширования запросов. Это, по сути, потребует второй реализации клиента с расширенными моделями представления.

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

Кажется немного излишним, если мне придется добавлять поле местоположения в каждую сущность или новую схему сущности, но я думаю, что избыточность стоит того, чтобы написать 2 разные реализации клиента, или есть лучший способ?

Я использую C# и Postgresql для моего сервера и клиентских приложений.

3. Клиент знает список мест, которые он запрашивает, и связывает каждый ответ с его местоположением, даже если ответ не содержит данных о местоположении

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

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