После перехода на отдельное хранилище для чтения пользователи жалуются: сохранённое изменение не сразу видно в списке. Как правильно к этому отнестись?

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

Приёмы:

• оптимистичное обновление — клиент сразу показывает сохранённое из ответа на команду, не перечитывая список;
• read-your-own-writes — собственные недавние изменения пользователя читать из модели записи или подмешивать к результату проекции;
• ожидание версии — команда возвращает версию (позицию события), а запрос на чтение ждёт, пока проекция её догонит (с таймаутом);
• честная индикация — «заказ обрабатывается», «изменения появятся через несколько секунд».

Что не делать: обновлять проекцию синхронно в транзакции команды — тогда модели снова связаны, и выгода разделения теряется.

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