Какой размер "большой" и долго для вас это сколько?

Это кэш какой-то? Какая производительность нужна?

Больше чем 50мс недопустимо

Нет, но это предстоит кешировать

А 50 мс на что? На то чтобы распространить изменение? Писатель не может ждать дольше 50 мс?

Читающий не может ждать больше 50

Очень загадочно все. Если у вас есть точные метрики и они критичны, то берите несколько решений и моделируйте нагрузку, начиная от CopyOnWriteArrayList заканчивая каким-нибудь Embedded Redis.

Если сейчас на этапе проектирования от вас требуется назвать имя класса, который это будет делать - то это странно, ИМХО. Опишите этот кусок как абстрактный модуль с заданными характеристиками, а потом выбирайте решение. Если этот модуль вообще нужен.

50 мс - это же безумно много, если про inmemory говорить.. Сколько там данных, что можно не успеть попасть в это значение?

Так он не будет ждать, почему он вообще чего то ждет?

50мс это гигабайт надо скопировать, наверно (надо тесты найти на мемкопи)

Ну надо потестить с Copy write тогда

А там делается move элементов в новый список при записи или прям копирование каждого элемента?

Под итератором я точно не буду писать

Только читать

Мемкопи должен быть и подмена массива с cas'ом, по идее

День добрый, подскажи плз, какая лучшая практика для взаимодействия spring webflux, и нормально ли использовать text/event-stream для нотификации ui через подписки на евенты?

взаимодействия между чем и чем?

А если придет злой гц и сожрет асе время, то что произойдет?

Фронт бек, т.е фронт по сути подпишеться через стрим на евенты, после чего будет собственно и работать web flux

одно из решений для этого - https://rsocket.io/