Trade offs using RDS cross region replicas with Entity Framework

user_518341 0
Viewed 277

Background

I'm looking at my options for architecting a Saas app which will be available in three countries (maybe more later). It will be run on AWS with RDS Postgres. Entity Framework Core is the ORM in the application logic, but this question could be considered for any ORM.

For the record, this is the first time I'm architecting a data layer of this complexity, and good resources are difficult to find (which I'm guessing is due to the difficult nature of cross region data handling).

Candidate Architecture

I'm currently assessing the suitability of running a master DB in Australia, and then creating read replica's (slaves) for the US and UK app servers. Writes will then obviously need to be sent to the Australian master from the US and UK app servers.

Three possible ways of using this archictecture with Entity Framework

  • A) A DbContext with a replica connection string reads from a replica to fetch entities into the context. The entity properties are then mutated. To save these mutations, I then attach them in an "update" state to seperate DbContext, instantiated with the master connection string, and then that context performs the write to the master in Australia on save.
  • B) For all create/update/delete operations, the entity is both read and written from the master database with a single context.
  • C) For all operations a singe DbContext is used, with is instantiated with a replica connection string. The entities are then read from the local replica, and then when save is called on the context, it sends them to the replica, but AWS routes any create/update/delete operations to the master database, automatically behind the scenes.

Considerations of those use cases

Out of these I like A the least because you lose half the power of entity framework when the entities become disconnected, and then you have to manage their state manually.

B seems like the easiest, but C seems like the best trade off (if it's even possible?) because you gain the lower latency on the read. However, right now I'm not sure of possible issues reading from one DB and writing to another. Or things I'm not seeing due to my early knowledge on this topic.

I'd be grateful if anyone has any experience/advice here, or better options?

rds latency amazon-web-services entity-framework
1 Answers

I've never tried this, but you could encapsulate or inherit from the dB context and override the save changes call. You could then copy all entities in the read replicas' dbcontexts' change tracker to an internal db context that is tied to the write db. This would be relatively straightforward and generic, and then after you could copy them all back to the read replicas change tracker. The downside of this approach is the overhead needed to copy the entities back and forth between change trackers in the respective dbcontexts.

user_11838860
Related