В целом под вычисляемыми свойствами я имел ввиду результат вычислений, который нужен и врайт и рид. Т.е. это даже не поле в сущности.

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

Ты же про csrf токены говорил. Они про безопасность, причём тут балансировка вообще?

никак) но sticky session довольно хреновая затея

еще раз, в симфони есть поддержка csrf токенов, они хранятся в сессии, сессия хранится на сервере1
есть балансировщик, запрос может пойти на любой сервер за ним, а их 2+
получим что токен верный, запрос пришел на другой сервер, там сессии этого пользователя нет - запрос обломается
sticky session это решают, не хочу их использовать
единое хранилище сессий тоже так себе вариант ибо создает единую точку отказа и нагрузка и масштабирование

вопрос был в том что может я где-то недочитал документацию и встроенный cqrs симфы поддерживает масштабирование на разные сервера и тп

Ну а я тебе говорю: csrf токены могут быть не нужны вообще, если юзаешь samesite грамотно.

вы видели поддержку этой фичи по браузерам ?

мне всех остальных юзеров обречь на страдания ?:)

Если тебе так нужно горизонтальное масштабирование, смотри в сторону jwt токенов и stateless модели.

и это я понимаю, плюсы и минусы тоже знаю
судя по всему придется генерировать токен при авторизации, добавлять его в httponly cookie, слать клиентом этот токен в хедере
и на сервере сравнивать данные из куки и хедера

пока другого адекватного ничего не придумал, без использования хранилищ и тп

спасибо, гляну

jwt токены хранятся в httponly куке, они не спасут от csrf атаки

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

да, хром держит с 80-й версии лакс, но требования проекта пишут что нужно поддерживать всех
поэтому и вот этот геморрой

Там как-то сильно заморочено, и похоже выбрали вариант с хранением на диске.

Моё мнение такое - реализация sticky sessions имеет сравнимую стоимость и хрупкость по отношению к распределённому хранилищу сессий.

Плюс давно есть возможность строить HA хранилища, где всё не упадёт от одного недоступного сервера.

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

И sticky session имеет дополнительные сайд-эффекты, что могут ухудшать возможности к масштабированию, что может быть важнее, чем CSRF

как я и сказал выше, знаю о недостатках и плюсах
изначальный вопрос был - умеет ли симфони из коробки масштабировать cqrs токены свои? (презентацию еще не изучил)