Key integrity

[vdbelt]

Due to the primary key constraint on the diagnoses key, duplicate submissions will fail with a 500 Internal Server error.

The question is whether feedback of duplicate submissions is wanted from a client point-of-view.

If not, the insert could fail silently or simply do an upsert instead (responsibility of the adapter).

Complexity will go up slightly if this feedback is wanted, considering:

• that the storage adapter might not have all information at hand upon inserting (think a HA master-master cluster)
• the format of the feedback itself (duplicate submissions within a batch).

[dstotijn]

I think for now we'll be fine if we silently ignore the conflict at the adapter (e.g. ON CONFLICT DO NOTHING for postgres). Semantically there should never be the case that a diagnosis key needs to be updated with a different day number. If a client attempts this, it must mean it made a mistake and it's trying to amend it. I don't foresee this being a real world use case. WDYT @vdbelt? Also, what are your thoughts in regards to database server replication?

[vdbelt]

I agree that silently ignoring on duplicates, also for the sake of simplicity, would be the best way forward for now. Making the assumption that the clients deal with this.

Depending on the scale of roll-out and to eliminate single point of failures, I could imagine you would want the backend and the database distributed in multiple locations with (eventual?) consistency between them. Keeping the flexibility that a local instance of the backend isn't working with all the latest data (due to network latency, failing nodes etc.), could save a headache later on in terms of scalability. And it is simple 👍