database - Scaling Identity service in multiple regions -

we have user database used creating/updating users , identifying (reading) them. read more write. write around 1 million/day , read around 100+ million. can separate read , write, afaik need strong consistency.

if start reading read replicas, consistent. there scenarios when user got created not available in read replica yet. or, user has updated information (name) , change not yet present in other regions.serving 1 region mean higher latency other regions.

we using rdbms. netflix's active-active blog read. big-big change. importantly need change in mindset of team/organization. also, take lots of effort right. need have in place slow responses troubling business. thus, trying explore other options can may give breathing space , time think of actual implementation.

as first step, planning have first level cache low ttl in different regions. reduce quite lot of reads. again consistent.

second step have cache invalidation in place. reduce inconsistencies bit. again consistent.

• what other options there?
• how companies google, facebook etc. scale?
• i not want sharding. or, should i? have auto-increments.
• is eventual consistency such big pain? have experience in read oriented scenario 1 read/write.

[edit] - based on comments/suggestions

here talking different aws regions. have single write system (1 rdbms), writes come 1 region only. implementing multi-region reads, async replication via db or custom (say sns + sqs or dynamodb streams) there delay because calls cross region boundaries. there failures due network issues can again account further delay (retries etc.).

yes, eventual consistency have account problems listed above. may have accept few inconsistencies , failures. may handle customer issues via support @ times. also, believe these issues less in comparison benefits , of times these issues temporary. trying find out better , simpler solution, if any. think problem many of trying solve or many have solved. thus, better take guidance , learn.

thanks in advance!!!

i feel solution (have read replicas across regions , have first level in-memory cache low ttl ) appropriate. serve customer in-memory cache. if user object not there in cache read replica --> store in cache --> serve it. if user changes suppose name; update in-memory cache , create asynchronus event ( sending jms message) update master db.

because u serving in-memory user see updated info.

note solution perfect because iam , not products information because user logged on single location @ time.