B>>Оба запроса кидаются в очередь хозяину карты. Хозяин их вычитывает из очереди и выполняет. Лочить карту ему не нужно, ведь он ее владелец — никто другой с ней не работает.

O>Но тогда очередь должна быть потокобезопасной, т.е. лочим не карту а очередь.
O>Например 2 потока пытаются одновременно добавить записи в очередь, а хозяин еще и читать ее пытается, если там не будет критической секции то может получиться непредсказуемое поведение.

Задачи эксклюзивного чтения или записи в очередь (или обращения к другому ресурсу), а также производитель-потребитель решаются стандартными средствами, которые есть в любом языке (mutex, условная переменная). Если же таких очередей и других ресурсов становится много и они зависят друг от друга, вот тогда и возникает потребность в какой-то "архитектуре" и фреймворках, реализующих эту более высокоуровневую абстракцию. Иначе тупики, гонки и глобальные блокировки, превращающие многопоточное приложение в приложение на питоне. И самое главное, при любом изменении приходится заново продумывать ВСЕ сложные зависимости, которые есть в приложении (иначе тупики, гонки и другие гейзенбаги многопоточки утекут в продакшн).

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