Why Stambecco

Why Stambecco?

Two of the most difficult issues in computing are cache invalidation and concurrency.  Stambecco addresses both.  Stambecco provides a coarse-grained cache (e.g., the granularity of a User on in a Twitter-like service) and a scalable model for enforcing concurrency in reading and writing the cache.

How?

Stambecco uses the Actor paradigm to manage concurrency.  All interaction with Stambecco entities (called Workers) is via immutable messages.  Messages are sent to Workers, either by other Workers or from outside of Stambecco, and placed in the Worker's mailbox.  On an available thread, the Worker deques the message and processes it.  Because only one message is processed by a Worker at once, there is no need to lock resources or engage in other explicit mechanisms for managing concurrency.  A Worker can modify its own state during message processing without need for any locking because the Worker is guaranteed that its resources are only being accessed by a single thread.

Further, because all messages are immutable (compiler-enforced), it is not possible to include a reference to mutable state as part of a message sent to a worker.  Also, this means that messages can be serialized in JSON format for distribution outside the local address space.

In addition to allowing messages to be sent to Workers from outside of Stambecco, external entities can ask questions of Stambecco workers.

All the logic for a particular entity (e.g., a Twitter user, a FourSquare venue) can be handled by a single Worker. All messages (including messages that are part of an ask/answer sequence) are serialized to a Worker.  This means that a Worker can effectively cache common requests (e.g., the most recent 40 items in a timeline or the current mayor of a venue) and answer questions without hitting disk.