Yeah, that'd be a straightforward way to do it. i.e. have two web servers and one worker, and set a worker-only config option like :com.example/enable-scheduled-tasks that you check for before starting tasks/while running tasks. If you wanted to try to get by with just two web servers, it'd still be doable, it just might take a little more finagling. Basically you'd want to use XT as a job queue in one way or another. Or just use an external cron service that hits your app with an http request instead.

Thanks for the reply. I’ve been considering both alternatives you mention as well. For XT as a job queue, I’m not ready to dive into that just yet, although I have some plans around reactive side-effects to events and domain state changes + transaction listening that I will eventually get around to exploring. I’m out of time for architectural exploration on this project though 😄 For the external cron job, I decided to keep things extremely singular at the moment in terms of tooling. Decoupling some basic scheduled jobs with a biff worker seems to be reasonable for this stage.

Sounds good! I have at times thought about trying to build in some kind XT-backed job queue into Biff, though for the time being on my own product I'm planning to just stick with one machine for as long as possible and then throw in Redis when I need to scale out ha ha. Perhaps a job queue would be another good thing to solicit community docs/proof-of-concepts for...

I see. I have actually been considering going the one machine approach as well to save some time at this stage. How do you think about fault tolerance in your case? Also is biff’s deployment functionality always a hot-swap or is there some downtime during a deployment?

Basically it's sufficiently early-stage that even if it goes down, not that many people would notice anyway. (I have like 50 daily active users, and it's a consumer product, so I'm not dealing with enterprise clients or anything). I figure I'll add machines when the risk of some downtime feels more important than the time it'd take to set up, maintain and pay for multiple servers. Not to mention that thus far I've incurred very little downtime anyway. As for deployment--the vast majority of my deploys are via hot-swap, so no downtime. Every once in a while I'll add a scheduled task that requires a restart. I do actually have a daily task that restarts the app process in the evening because I've got a memory leak somewhere (maybe related to core.cache; according to reddit there are some issues with it apparently?) and so far have been too lazy to chase it down.

(Which perhaps gives you more insight into how much I worry about downtime 😉 )

Haha, yes a useful and grounded perspective, thanks. So adding a new task requires a full restart? Ah I see, so the hot-swap is what bb soft-deploy is for.

> So adding a new task requires a full restart? Yeah, or at minimum a bb refresh which will restart the biff system without restarting the jvm and will thus be faster. > Ah I see, so the hot-swap is what bb soft-deploy is for. And also bb prod-dev which is what I usually use (it calls bb soft-deploy whenever you save a file)

Though if I've been developing something locally then I typically use bb soft-deploy afterward

I see, thanks for the insight!