Today, several clients are requesting current augmented diffs more or less at the same time via a call to /api/augmented_diff?id=xyz. This approach does not scale to a higher number of clients, as each query takes about 5-30 seconds, consumes quite some CPU cycles, but effectively returns exactly the same result.

I'm proposing a few changes to this process:

• Keep the most recent 60-120 augmented diffs precalculated on disk, possibly as compressed files. Maybe also for a longer period of time.
  Compared to the previous approach which kept everything on disk, this approach should keep the disk space requirements low
• Precalculate most current augmented diff right after update_from_disk completes
• Announce newly available diff via augmented_diff_status only after precalculation
• Serve most recent augmented diffs via disk cache only, avoiding the query execution altogether. Older augmented diffs (outside 60-120 buffer range) may still trigger query.

Pros:

• Much better scalability to a larger number of data consumers
• Less overall system load
• Less frustration for data consumers due to 429 error messages

Cons:

• None
• (maybe a few seconds more delay for data consumers)

Thanks to @pa5cal for suggestions.