> But in most cases replication lag can be worked around with simple tricks: for instance, when you update a record but need to use it right after, you can fill in the updated details in-memory instead of immediately re-reading after a write.

I found myself truly confused by this one - does this actually need stating? Do people actually re-read immediately after a write? Provided you got confirmation that a write was successful and the data doesn’t have anything that an SQL trigger would change, what would be the point of an immediate read instead of just using the DB “successfully written” response as a go-ahead to just update the in-memory data?

▲ porridgeraisin 4 days ago | parent | next [-]

Here's why it happens:

A lot of the time the datastructure you pass into writeAPI(obj) is different from the datastructure that is returned from readAPI(obj) -- even if the information contained is the same!

No one wants to do that data structure transformation and potentially miss an edge case/break some implicit assumption about the data structure some fuckall downstream consumer has.

However it is already done in the readAPI() function. So latency and throughput be damned, let us do:

  writeAPI(objects)
  objects = readAPI(objects)

To be clear, I'm talking about the typical bloated data structure we all know and love: 20+ fields, different fields redundant for different services, sometimes they are empty in which case we have to fall back to calculate that field differently. And it is this hacky due to a quick bug fix during a sev1 last year that was never revisited to be fixed "correctly". There is a ticket hanging around somewhere to do this, but the assignee has left the company.

▲ 4 days ago | parent | prev | next [-]

[deleted]

▲ sfn42 4 days ago | parent | prev | next [-]

At the very least you need to read the DB-generated ID, otherwise how do you provide stuff like editing?

Simply reading after a write is a perfectly adequate solution for I'd say most systems.

If you have performance issues and a change like this may solve them, sure. Switch to app-generated IDs and add workarounds for whatever other issues arise, and skip the read. But if you don't need to I don't see why you'd go through this trouble.

	▲	rekabis 4 days ago \| parent [-]
		> At the very least you need to read the DB-generated ID, otherwise how do you provide stuff like editing? Most of my career has been with MSSQL, but it can provide that after an insert as a part of the confirmation that the insert was successful. No explicit separate read required.

▲ sethammons 5 days ago | parent | prev [-]

They do all the damn time. We have write pressure and teams insist they must read their writes. No, no you don't. There are options and they are not rocket surgery.