Caching in Microservices & Monitoring
In a microservices architecture, each service may have its own cache — but shared data creates invalidation challenges. When the Product Service updates a price, the Cart Service, Search Service, and Recommendation Service may all cache stale product data. Event-driven invalidation via a message bus (Redis Pub/Sub, Kafka) is the standard solution: publish product.updated, every service drops its local and distributed cache entries for that product.
Monitoring separates a healthy cache from a decorative one. Track hit ratio (target: >90% for read-heavy workloads), cache latency (p50, p99), memory usage, eviction rate, and connection count. Alert when hit ratio drops suddenly — it usually means a deployment invalidated keys, TTLs are too short, or access patterns shifted. Tools: Redis INFO command, Prometheus + Grafana dashboards, Datadog cache analytics.
Check your understanding
How do microservices invalidate shared product data?Show answerHide answer
Answer
Publish an update event; each service drops its local/Redis entries for that id.Which metrics matter most?Show answerHide answer
Answer
Hit ratio, cache op latency (p50/p99), memory/evictions, and sudden hit-ratio drops after deploys.What does a sudden hit-ratio drop often mean?Show answerHide answer
Answer
Key namespace change, too-short TTLs, invalidation flood, or traffic mix shift.