Data Access and Data Sharing in Microservices
summary
Five concrete patterns for accessing data outside a service: option one: REST inner‑service calls (simple but adds latency, tight coupling and cascading failures), option two: schema replication (zero read latency but hard consistency, contract and update orchestration), option three: in‑memory replicated cache (Hazelcast, Ignite, GemFire, Coherence, Finnspan — ultra‑fast but cold starts, memory blowup and replication limits), option four: external data sidecar (owned cache per domain, removes invalidation pain but adds an external fault), and option five: shared data domains (share databases across a small set of services to avoid cross‑service joins at the cost of coordinated changes, connection scaling and stricter governance).
AI-written summary · about
chapters (8)
- 0:00Introduction to data challenges
- 3:15Option one inner service communication
- 6:01Option two data replication
- 9:13Option three in-memory caching
- 16:05Option four data sidecar
- 25:42Option five data domains
- 32:27Data topology and sharing
- 52:30Conclusion and Q&A
related talks
43mData Access and Data Sharing in Microservices
51mData management in a Microservices world
27mData Consistency in Microservices Architecture
47mArchitectural Patterns for Caching Microservices
54m3 Patterns for Scalable Microservices
45mWhere is my cache? Architectural patterns for caching microservices by example
44mA Software Engineer's Journey Through Microservices Data Sharing
30mDatabases in the Microservices World