Very cool. Is there any need to wait until after pushing to rethinkdb before updating the websockets? I'd look for I/O concurrency here and block until they're all complete.
The entire convert/save/push to websockets activity though, is done on a separate _fibre_ in Crystal - essentially a spawned background thread. So even if one packet went awry, it shouldn't really block subsequent packets from coming through. I suppose I could go further, and within the spawned fibre, I could spawn another fibre for the write ops so it didn't get in the way of the web socket push op.
But then again, when I checked the Crystal CPU and memory footprint, it was really low, and even at the highest UDP telemetry rate of 60Hz, I don't think I lost any packets due to Crystal's sheer speed of handling them.