- 最新
- 最多得票
- 最多評論
There are a few things you can keep in mind in dealing with read-after-write staleness. First, do you really need to immediately read after the write? If you just successfully inserted a row, you know what it should look like, right? Second, if you made some kind of incremental change to a column's values, you can probably find some way to have the database return that row to you as part of the response to the write - for SQL, take a look at the RETURNING clause - for DynamoDB take a look at the ReturnValues parameter on the UpdateItem API. Finally, if you are making some kind of more complex query after the write (involving multiple rows etc) and you must see the result of that write within your query result, you might just need to direct the query to the leader node (just as you did for the write).
BTW - it's important to realize that when you read after the write, there's no guarantee that you'll see your data just as it was when your write was applied - it's always possible that some other process came along and changed things in the meantime!
Hi, thanks for your answer. What do you recommend when the application that reads is not the same that writes? In my case, the writer application sent an event to a message queue after the write, and another application reacted to the event and attempted to read the data. What I observe is sometimes the event is faster than the database replication.
Got it - so the reader is quite independent from the writer. I think there are probably a couple of different approaches for this. First would be to direct the read from the event driven process to the leader replica - the writer endpoint. Another would be to stay with making reads from the read replicas, but introduce some delay in the event processing - perhaps with some retries to handle scenarios when the (I would suggest using an exponential back-off on these retries).