Здравствуйте, Sharov, Вы писали:
S>>>Про синхронизацию + какой-нибудь враппер, это реализующий, для библиотеки этого api. G>>Враппер?
S>Кроме шуток, а как иначе, если экземляр класс, реализ. это api не потокобезопасен? Завернуть в потокобезопасный S>декоратор какой-нибудь.
Ну я описал же — с помощью микросервиса или FaaS. Потому что легче масштабировать. Кодовый враппер фиг отмасштабируешь когда нагрузка попрет (а она попрёт, т.к. складывать два числа — это очень частая операция).
С кодовым враппером ты решишь только проблему синхронизации и проблему коммуникации между потоком-владельцем и потоком-потребителем, но не проблему увеличения нагрузки, т.к. в плане масштабирования ты остаешься в вертикальной плоскости масштабирования, а это дорого. А ты наверное сначала подумал, я шучу про микросервис?
тут конечно можно возразить, что сложение двух числе — это очень простая и быстрая операция. Но ведь кодовый враппер не продашь и не сдашь в аренду, на них не заработаешь, а FaaS — еще как! Вопрос о том, как продать такой сервис — это уже пусть уважаемая компания задает этот вопрос на собесах своим маркетологам.