I am not opposed to this solution, but I'd like to propose an alternative to consider:

• At spark-evaluate startup, make an RPC API call to fetch recent MeasurementsAdded events all the way up to the beginning of the current round. See how dry-run does that:
  

  spark-evaluate/bin/dry-run.js

  Lines 215 to 257 in 0d1cce3

  	async function fetchMeasurementsAddedFromChain (contractAddress, roundIndex) {
  	const { ieContract, provider } = await createMeridianContract(contractAddress)
  	console.log('Fetching MeasurementsAdded events from the ledger')
  	const blockNumber = await provider.getBlockNumber()
  	// console.log('Current block number', blockNumber)
  	// TODO: filter only measurements for the given `roundIndex`
  	// See https://github.com/Meridian-IE/impact-evaluator/issues/57
  	// max look-back period allowed by Glif.io is 2000 blocks (approx 16h40m)
  	// SPARK round is ~60 minutes, i.e. ~120 blocks
  	const rawEvents = await ieContract.queryFilter('MeasurementsAdded', blockNumber - 1800, 'latest')
  	/** @type {Array<{ cid: string, roundIndex: bigint, sender: string }>} */
  	const events = rawEvents
  	.filter(isEventLog)
  	.map(({ args: [cid, roundIndex, sender] }) => ({ cid, roundIndex, sender }))
  	// console.log('events', events)
  	const prev = roundIndex - 1n
  	const prevFound = events.some(e => e.roundIndex === prev)
  	if (!prevFound) {
  	console.error(
  	'Incomplete round data. No measurements from the previous round %s were found.',
  	prev.toString()
  	)
  	process.exit(1)
  	}
  	const next = roundIndex + 1n
  	const nextFound = events.some(e => e.roundIndex === next)
  	if (!nextFound) {
  	console.error(
  	'Incomplete round data. No measurements from the next round %s were found.',
  	next.toString()
  	)
  	process.exit(1)
  	}
  	return events.filter(e => e.roundIndex === roundIndex).map(e => e.cid)
  	}

• For each event found, call the preprocess step.

Upsides:

• The service will not need any persistent volume.
• We don't have to write & maintain complex code to manage a ringbuffer.

Downsides:

• When there is an outage of the RPC API, or if the eth_getLogs call takes long time to complete, then spark-evaluat will need a lot of time before it starts & can handle events. (This can be mitigated, though. E.g. the startup does not have to wait until we get all events.)
• On restart, we have to re-fetch measurements from older round events.