Sub-minute server-side execution for real-time game timers — is it possible on Appwrite Cloud?

Hey — I'm building a real-time auction app on Appwrite Cloud and running into a timing limitation I'd please love some clarity on.

My use case: when a bidding timer expires (e.g. 20 seconds), I need the server to automatically close the lot and trigger the next lot within a few seconds — even if no clients are connected.

Currently I'm using:
• A 1-minute cron function as the server-side backstop
• Client-side polling hooks (every 10s) as a faster fallback when the app is foregrounded

The problem: the minimum cron interval is 1 minute, so if all users have closed the app, there can be up to 60s of dead time between each lot in an auction. For a 20s bidding timer this feels broken.

What I really need is something like Elixir's GenServer — a persistent process that can schedule a callback for exactly deadlineTs - now() milliseconds in the future.

My questions:

1. Is there any way to achieve sub-minute server-side execution on Appwrite Cloud beyond the 1-minute cron minimum?
2. Are there plans to support shorter cron intervals (e.g. every 10s or 30s)?
3. Is there a pattern others use for real-time game timers on Appwrite that I'm missing?

Happy to share more context about the architecture if useful. Thanks! 😊

https://tenor.com/view/anyone-here-tumbleweed-john-travolta-pulp-fiction-where-are-you-gif-22041899

https://giphy.com/gifs/thefreshprinceofbelair-season-3-fresh-prince-of-bel-air-the-XDY7T4JQJ8M5p3hA6n

@Meldiron would love to confirm with you on this but from what I remember, the standard Linux cron implementation does not support sub-minute scheduling.

The sleep loop only makes sense if the underlying app is perpetually running (doesn't make sense for a serverless function).

@Chris One thing I would personally try is to keep a 1 minute interval on the cron job for the function and set a 20second interval to trigger the auction lot processing jobs in there. Once 3 jobs are processed, the lifecycle of that function execution can end and by then, the next execution would start on a timer.

Also, @Chris I just noticed that you're a Pro user. In the future, you can also raise a support ticket through the Appwrite Cloud console, which are dealt with on priority.

Thank you for your reply

Indeed, things happening more often than 1 minute feels more like a queue or realtime server, than a schedule.

Your sleep approach should work fine - as long as you do some sort of ping every minute using CRON, the container will continue living. But personally I would prefer stateful container for such logic, instead of serverless. If we take this scenario to extreme, we would end up with a gaming server that has tick system and needs to execute a physics loop 20 or 60 times per second. While totally doable, serverless instracture would be more of a burdon than benefit for such gaming server.

Let me ping @Steven too, maybe he has some good practices recommendations, when achieving this on serverless.

Thanks for the insight — that's really helpful framing. You're right that what I'm building is closer to a gaming server than a typical serverless use case.

I think the right long-term architecture is a hybrid approach:

• Keep Appwrite for what it's great at — auth, database (all collections), and Realtime (WebSocket push to clients). The React Native app continues talking to Appwrite directly.

• Add an Elixir/Phoenix layer with GenServer to handle the time-sensitive game logic — specifically the auction lot close timer and bidding clock. One GenServer per active lot, each scheduling a process for exactly (deadlineTs - now()) milliseconds. When it fires, it calls Appwrite's REST API to close the lot / advance the bid, and Appwrite Realtime pushes the update to clients as normal.

This way Elixir only replaces the clock engine (3-4 handlers), not the entire backend. Everything else (bid placement, lot nominations) stays in Appwrite Functions for now.

A few things I'd love your thoughts on before I build this:

1. Appwrite Realtime from Elixir — is there a recommended way to subscribe to Realtime events from an Elixir process? Or would I rely purely on event-triggered function calls (document update → trigger) rather than a persistent subscription?

2. Authentication — for the Elixir server to write to Appwrite collections (e.g. update a lot to status: sold), what's the recommended auth approach? API key with server-side privileges, or JWT?

3. Supervision — if a GenServer process crashes mid-auction, an OTP Supervisor would restart it. But it would lose the in-memory timer state. Is there a recommended pattern for rehydrating state from Appwrite on restart?

4. Hosting — any recommendations for hosting a small Elixir/Phoenix app that needs to be always-on alongside an Appwrite Cloud project? (Fly.io seems like a natural fit given their Elixir roots.)

Thanks again — this has been a really useful thread.

Appwrite Realtime from Elixir — is there a recommended way to subscribe to Realtime events from an Elixir process? Or would I rely purely on event-triggered function calls (document update → trigger) rather than a persistent subscription?

Yes, since you have a server, you can set that server up to have an HTTP endpoint that receives events.

Authentication — for the Elixir server to write to Appwrite collections (e.g. update a lot to status: sold), what's the recommended auth approach? API key with server-side privileges, or JWT?

Your server should perform the necessary validation and then use an API key to interact with Appwrite.

Supervision — if a GenServer process crashes mid-auction, an OTP Supervisor would restart it. But it would lose the in-memory timer state. Is there a recommended pattern for rehydrating state from Appwrite on restart?

Up to you. You can store state somewhere or make it so that re-running something will be fine.

Hosting — any recommendations for hosting a small Elixir/Phoenix app that needs to be always-on alongside an Appwrite Cloud project? (Fly.io seems like a natural fit given their Elixir roots.)

No, up to you