@abhishekanantvajarek
Nothing here yet.
Nothing here yet.
Eugene Chernysh We prioritize failure scenarios based on what’s most likely to go wrong and how it could affect the system. For exmaple, we first test things like network lag or databse issues, since those are pretty common. When it comes to balacing how deep we go with testing, we make sure to test in isolated enviroments first, with good monitoring to avoid messing up production. We focus on depth, but always make sure there are recovery steps ready if anything goes wrong.
There wasn’t one "most challenging" part, but rather a series of hurdles we had to address. One challenge was ensuring chaos tests didn’t accidentally impact production or end-user experience, like simulating network latency without affecting live traffic. Another was managing non-critical dependencies that could still cause cascading issues. We solved these by setting up tight monitoring, isolating failure points, and ensuring recovery mechanisms like circuit breakers and rollbacks were ready to act, which allowed us to minimize disruptions.
Hitesh Sanjay Nalamwar it's usually best to go for an immediate cache refresh. However, to minimize the performance hit, you could combine immediate invalidation with a lightweight refresh strategy. For example, you could invalidate the cache immediately but fetch the updated data asynchronously in the background. This way, users still get the most up-to-date information, but the performance impact is minimized.
Hitesh Sanjay Nalamwar When multiple updates happen quickly, you can use cache batching or delayed invalidation. With batching you wait until all the updates are done and then refresh the cache just once instead of invalidating the cache after every update . Delayed invalidation works similarly -- by holding off on invalidating the cache for a few seconds. If another update comes in during that window, you delay the cache refresh until everything's done. Both approaches help avoid unnecessary cache invalidations and keep things running smoothly
Cache invalidation can be tricky, but a good mix of strategies usually works best. You can set an expiration time (TTL) for cached data so it refreshes after a certain period. If your data changes due to specific events (like a user update), you can invalidate the cache for that data. Another option is versioning, where you change the cache key whenever the data structure changes. It’s all about finding the right balance between keeping data fresh and maintaining performance.
Good one, thanks! To balance cache eviction with data freshness, we use shorter TTLs for frequently changing metadata (like user preferences) and longer TTLs for static content (like videos). For video content, we implement versioning and cache purging to ensure users always get the latest updates without hitting the server too often. We also stagger cache expiration and use cache prefetching to maintain freshness and reduce load. This helps ensure a balance between performance and data accuracy.
When choosing between geographic redundancy and region-based failovers, the main trade-off is latency versus cost. Geographic redundancy offers higher availability across continents but comes with higher costs and potential latency. Region-based failovers are cheaper, with lower latency, and are ideal for most systems that don’t require global disaster recovery. The decision depends on your business needs and risk tolerance—if global availability is crucial, go for geographic redundancy; otherwise, region-based failovers usually provide a good balance.
