I am not criticising this idea - I love the thinking and its definitely worth exploring - but I wanted to point out why it won’t work for the elm-serverless use case.
Basically, with AWS Lambda functions you have no control over the lifecycle of the underlying runtime. Which is kinda the point, you let AWS figure that out for you. But it means that you cannot guarantee your runtime will stick around for any length of time. So if I read all the events into memory ready to be queried, I could process just 1 request, and then the whole thing gets chucked away and needs to be re-done for the next request.
Not sure, but maybe AWS provides a way to hook into the init phase of a Lambda to do the event loading. If requests are coming in fast enough I think AWS will manage to keep the same runtime alive to process many - so perhaps this idea not a complete dead end.
It would be nice if I didn’t have to use a database, but so far my Elm AWS Lambda functions have tended to involve mutiple sequential IO operations. Which is why I have been looking at the elm-procedure way of doing things with a lot of interest.