How Geo-Distributed Apps Use Global Cloud Infra
summary
Concrete claims and patterns anchor the decision: a Slack‑like messenger is implemented with messaging/profile/reminders/status microservices collocated with a distributed SQL storage called yoga by db, data partitioned by a country column so EU records stay in EU nodes, and three multi‑region options are compared — a single geo‑distributed cluster, a primary with read replicas, or independent clusters with async replication. Measured latencies justify placement (e.g. 60 ms US coast‑to‑coast, 130 ms to London, 220 ms to Mumbai) and a global anycast load balancer handles nearest‑region routing and failover.
AI-written summary · about
chapters (8)
- 0:00Intro
- 1:39Global Cloud Infrastructure: Regions
- 12:08Geo-distributed Apps: Common Deployment Types
- 15:17Architecting a Slack-like Corporate Messenger
- 23:50Multi-Region Database Deployment With Read Replicas
- 25:59Multiple Standalone Databases With Async Replication
- 29:13Multi-Region Application Layer
- 31:50Cloud Load Balancer: Automatic Forwarding for User Traffic
related talks
38mHow To Build a Distributed System (And Should You?)
04mMatt Galligan
29mFollowing the Data: A Deeper Look into Distributed Applications
05mGetting to Know SimpleGeo
15mDistributed Caching & Queueing in the Cloud
20mScaling Microservices and Distributed Databases in a Multi-Cloud World
38mHighly Scalable Consumer Applications using Cloud Native Open Source Tools
30mClient and server, 3 meters above the Cloud