Requests to be done idempotently —

to be idempotent in a distributed way there should be a unique marker at receiver level (DB level ) .

Senders can be — many , concurrent which may interleave badly , locks help with wrong interleaves .

Without unique constraint at db level for row insertions — code to be written extremely carefully to ensure idempotency and it also hurts latency and throughput as locks will be required .

With locks at db level ( if done carefully while avoiding deadlocks) —

• we can guarantee eventual consistency if full idempotency is not necessary .
• it is also possible that we make it truly idempotent but it depends on use case .(to be tested )

writing code for insertions best practices —

• handle already exists integrity and other integrity exc’s separately.
• if using core make sure sql injection safety

Core insert() does not require to specifcially add if column is nullable or has a server default.

Yes — for Core inserts, autogenerated columns should ideally be DB-generated (server_default) rather than passed from code.

using core — make sure to give server defaults for autogenerate fields like public ulid —> this way we don’t need to specify them in code while inserts —>

adding autogenerates by ourselves is error prone if not done carefully —>