5 ms·

I’ve been building a durable execution framework with roughly the same mechanism. It’s a pretty logical rough edge to try shave off from Temporal-like systems.

elendilm 5d ago
Congratulations. I am curious about what prompted you to build a durable execution framework. We didn't know we were building one until later as that is where our application development trajectory naturally lead us.
- ShinyLeftPad 5d ago
  How did you know you need one?
  - elendilm 5d ago
    Good question. Building for extreme scale constrained the possible architectural space. For a high level overview of the application architecture, refer to the seperate comment here in this thread. It started initially by realizing that our app, Slyp, requires extremely distributed invoice and coupon processing as we started rolling out. So the architecture must handle such scale without issues. This lead to persisting every incoming request (for commands) from the frontend and dismissing them only to be informed later of continuing with the status. This avoids processing requests when the system is overloaded with high traffic. So naturally the minimum is a log style ordered persistence. Initially kafka. Later our own Monolog built in rust which is substantially faster for our workloads and zero jvm and low memory and can run on servers and mobile alike. Naturally the right point to consume this was into the command ingestion point in the Feature Architecture as noted in the other comment. This expanded the capability to all feature invocations including inter and intra service feature invocations. This then progressively evolved into a much capable engine at which point we realized, this is a durable execution engine for command features but as a minor part of the whole Feature Architecture itself.
- iand675 5d ago
  Good question. I operate a pretty big Temporal deployment at work (~3.45 billion actions per month), and also have the dubious distinction of being one of the only community SDK (Haskell) implementors for Temporal. So I have a pretty good sense of rough edges and my own areas of dissatisfaction, and also what I'd want out of a next generation system. So, hello frenemies, I suppose :)
  - hypervs 5d ago
    Which rough edges pushed you toward the same mechanism - history growth, replay latency, determinism/versioning, worker ops, or the programming model? Happy to compare notes.
  - elendilm 5d ago
    Definitely friends, not frenemies. I have nothing but genuine respect for builders out there solving hard infrastructure problems. We are primarily focused on our Feature Architecture. Durable execution is only for command features, requires tight coupling with our architecture, and is not a standalone dedicated tool like Temporal. Open to further discussion on both of our work's trajectories rather than digress here.

elendilm 5d ago

Congratulations. I am curious about what prompted you to build a durable execution framework. We didn't know we were building one until later as that is where our application development trajectory naturally lead us.

ShinyLeftPad 5d ago
How did you know you need one?
- elendilm 5d ago
  Good question. Building for extreme scale constrained the possible architectural space. For a high level overview of the application architecture, refer to the seperate comment here in this thread. It started initially by realizing that our app, Slyp, requires extremely distributed invoice and coupon processing as we started rolling out. So the architecture must handle such scale without issues. This lead to persisting every incoming request (for commands) from the frontend and dismissing them only to be informed later of continuing with the status. This avoids processing requests when the system is overloaded with high traffic. So naturally the minimum is a log style ordered persistence. Initially kafka. Later our own Monolog built in rust which is substantially faster for our workloads and zero jvm and low memory and can run on servers and mobile alike. Naturally the right point to consume this was into the command ingestion point in the Feature Architecture as noted in the other comment. This expanded the capability to all feature invocations including inter and intra service feature invocations. This then progressively evolved into a much capable engine at which point we realized, this is a durable execution engine for command features but as a minor part of the whole Feature Architecture itself.
iand675 5d ago
Good question. I operate a pretty big Temporal deployment at work (~3.45 billion actions per month), and also have the dubious distinction of being one of the only community SDK (Haskell) implementors for Temporal. So I have a pretty good sense of rough edges and my own areas of dissatisfaction, and also what I'd want out of a next generation system. So, hello frenemies, I suppose :)
- hypervs 5d ago
  Which rough edges pushed you toward the same mechanism - history growth, replay latency, determinism/versioning, worker ops, or the programming model? Happy to compare notes.
- elendilm 5d ago
  Definitely friends, not frenemies. I have nothing but genuine respect for builders out there solving hard infrastructure problems. We are primarily focused on our Feature Architecture. Durable execution is only for command features, requires tight coupling with our architecture, and is not a standalone dedicated tool like Temporal. Open to further discussion on both of our work's trajectories rather than digress here.