Не очень понятно, как конкретно модель акторов помогла кейсу из начала видео. По крайней мере вторая часть видео описывает сам подход абстрактно. Тут бы закончить примером как решилась начальная проблема. 1. Клиент перестал ожидать завершения запроса - ок, перевели задачу в асинхронную. 2. Как ушла потребность не использовать SELECT FOR UPDATE не совсем понял - мы разбили всю транзакцию на 2 актора/консьюмера? Правильно я понимаю эти шаги? 2.1 сначала посылаем сообщение актору, который проверяет принадлежность к санкционным спискам, 2.2. актор в случае успеха посылает сообщение другом актору, который деньги переводит, но вот тут все равно нужно убедиться, что мы проблему LOST UPDATE решили. То есть внутри этого актора будет какой-нибудь OPTIMISTIC LOCK. Получается, акторная модель превратила много LONG LIVED TRANSACTIONS в много-много SHORT LIVED TRANSACTIONS, так? Якобы часть ожидания локов из БД превратилась в ожидание очереди задач для актора, но внутри самих акторов транзакции быстро проходят.