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

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

Если событие - очередь - обработка, то получается какое-то время данные будут не консистенты

ну повторюсь, я бы в твоем случае вообще не парился бы и делал запрос в стиле SELECT DISTINCT ON(theme_id) и джойнил бы уже темы туда, но это если у тебя постгрес, тогда индексы бы разрулили

или не джойнил бы и применил бы мои любимые application side joins :)

ну повторюсь, я бы в твоем случае вообще не парился бы и делал запрос в стиле SELECT DISTINCT ON(theme_id) и джойнил бы уже темы туда, но это если у тебя постгрес, тогда индексы бы разрулили

или не джойнил бы и применил бы мои любимые application side joins :)

Почему они твои любимые?

А если ты джойнишь датасет из таблиц без фк в одном запросе - это тоже же application side joins?

нет. application side joins это когда "приложение джойнит данные". то есть два запроса. Список постов, потом комменты по where post_id = ANY(:posts) а потом склеиваешь это дело. Типичная история с каким-нибудь graphql и прочими api gateway

Почему = ANY а не IN ?

тоже верно, в одной транзакции лучше, но нарушение консистетности все-таки возможно. кол-во не критично, вот последний коммент может не сойтись