We built Locklock mainly because simple patterns of distributed locking kept coming up in our system designs.
The common use case is ensuring multiple components of a distributed system take turns accessing a shared resource.
A special case of that is guaranteeing a particular operation takes place at most once. For example, some AWS services guarantee at-least-once delivery, but sometimes consequences of these events need to execute exactly once. To accomplish this, simply acquire a lock for the identifier representing the originating event and don't release it.
Our secondary motivation was to unify locking logic across components of a distributed system, which may be written using different programming languages or deployed accross multiple cloud providers. By using Locklock, they only need to know how to communicate with a simple REST API.
Would really appreciate feedback from the community!
When someone in a sports psychology session broke down motivation into internal vs external [1], they changed the way I would approach anything I do from then onwards. Literally changed my life in 20mins.
We stayed away from implementing more advanced locking features in the initial version, but since it came up this early we'll definitely work on it.