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

Но для хорошего масштабирования разделения API на чтение/запись недостаточно. Нужно разделить и базы данных, с которыми это API работает. Тут нам на помощь приходит EventSourcing. Он предлагает нам хранить всем события системы в одной базе данных, назовем ее EventStore, а все остальные базы данных и таблицы строить уже на ее основе.

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

В этой статье мы рассмотрим один из нюансов проектирования клиентской части для такой системы — оптимистические обновления в UI.