Let us know, what you think about it :-)
The order in which events are processed for each key is their arrival order. If you need to handle out-of-order events, then you can implement this as part of a virtual object which can store events and re-order them based on other events that carry some form of watermark or based on time.
The goal is a highly-available, transactional, scalable, and low latency runtime in a self-contained binary that scales from laptop to complex distributed deployment.
Restate itself sits in between your services and your user's requests. It is designed to push invocations to your service endpoints which allows it to play nicely together with serverless platforms such as AWS Lambda, Cloud Run functions, etc.
Disclaimer, I'm the CEO of the aforementioned DBOS.
That's an interesting way to phrase it. We like to think that we've taken advantage of 50 years of development on DBMS by optimizing how it is used. We also take advantage of the fact that your application is already accessing the database for application data, and we sit right next to it, not on another service. So our added latency is in the single digit milliseconds (an order of magnitude faster than any external solution).
Since we are on the same database as your application data, our throughput scales with your application seamlessly as you scale your database to meet your application needs. It's part of our lightweight promise for durability -- no external services required.
