Yup, very aware that the ingestion endpoint is going to have to do a read in order to do the update.  It will be a fast read (primary key lookup) and storing shouldn't be a problem either.  

The reality of the scale of bolus events (doing more than 20 a day is probably a 0.1% occurrence and more than 50 a day per user is 0.001%) mixed with the fact that the completion should happen relatively soon after the start (i.e. the start will likely still be in memory) means that we will have to have a significant number of users before the overhead of a read-modify-write for boluses in the ingestion API is going to cause scaling concerns.  And, if we have that kind of user base, I imagine that we will already be employing sharding mechanisms and other such things to help mitigate the effects...

Note that the requirement of a provenance system is already requiring that we have "mutable" data structures.  That is, we are storing provenance because we want to be able to make changes to events that happened in the past.  Updates from this would also be subject to the provenance (it's a change to the event happening *after* it has entered our walled garden).

Fwiw, the current visualization code's stats widget would barf on a basal being re-started with a start at 12:07.001, because that is a millisecond gap when insulin wasn't delivered.