Also, services are expected to generally keep up with demand, so the deferred message buffer with generally be short and empty often. This is true of any service. If it’s protected by a serializer, messages will pile up in the deferred message buffer. If not, messages can still pile up in the message delivery system of the actor runtime. I expect to be posting a few articles that address this issue by providing back-pressure and flow-control among producers and consumers.

The implementation details of the queue, like any actor, are conveniently encapsulated behind the asynchronous messaging interface. You are free to use any representation you like within the actor’s behavior, as long as you support the expected message protocol. The implementation I chose here has O(1) performance.

I have a question regarding the functional nature of the solutions. Is this part of actor model or is it specific to humus or is it just the way you prefer to do it?

For example, is it ok to implement an queue using on actor that keeps an internal list to hold items since the actor process one message at a time?