<p>Hi,</p>
<p>i am currently developing a backup framework which uses OpenAPI and Open Service Broker API to define a generic backup process for CloudFoundry & Kubernetes.</p>
<p>I want my API to be stateless.</p>
<p>Now the problem:
I have a backup manager which is concerned with the orchestration of backup tasks and i have many backup agents. The agents are colocated to the instances i intend to backup. Each agent is reachable through an API by the backup manager and the manager can order a backup task at the agent and receive the backup status at all time.</p>
<p>All backup tasks requests are immediately stored in the postgresql db of the manager with status pending.
Now i need to update the status of every pending backup task periodically in the postgresql db by calling the agents status endpoint. </p>
<p>My question is how can i realise this periodic update within a stateless API design?
I came up with two solutions:</p>
<p>1) My backup manager starts a cron process (see <a href="https://github.com/robfig/cron">https://github.com/robfig/cron</a>) next to the api. The cron process will request the status for every pending backup task in the postgresql db on the belonging agent and update the status in the db.</p>
<p>2) I extract the croj process in a seperate status deamon and colocate it with the backup deployment.</p>
<p>Which one would you choose, and in case i do 1) am i still stateless?
Maybe you have a better solution for this? </p>
<p>best,</p>
<hr/>**评论：**<br/><br/>_ntnn: <pre><p>Have a job queue in the manager. The manager starts a job to update the status of a given agent - if the agent did not finish queue the task again. If it is finished update the status in the database. I don't know of a go project that supports rated queues, but you may find one. And extending an existing worker/queue library might not be hard.</p>
<p>You could also go with a looping/sleeping adhoc goroutine, but handling a lot of jobs roughly at the same time will considerably worsen the performance.</p></pre>
