Hrudwik Dhulipalla

⚡ Scaling Infra to Handle High Traffic – Caching Layer at Internshala At Internshala, we were initially relying heavily on our primary database for everything — even for frequently accessed static data. This created unnecessary load and latency, especially during high-traffic periods. As a result, the pressure on our production database increased as Internshala’s traffic scaled. One of the golden rules of scaling infrastructure: 👉 Minimize direct hits to your production database. 📦 Why Caching? - Reduces DB load by serving repeat requests from memory - Improves response time drastically - Creates bandwidth for handling higher concurrent traffic on the same infra 🧰 Our Caching Strategy We introduced a dedicated caching layer using Memcached and Redis, depending on the nature of the data: We adopted a two-pronged caching approach: ✅ Memcached - For simple string/static data - Rare updates/deletes - Lightning-fast read/writes ✅ Redis - For structured or sorted data (arrays/objects) - Frequent updates/deletes - Ideal when order of data matters (previously handled via MySQL sorting) 🔍 Our Approach - Identified frequently requested data - Decoupled those queries from the DB and introduced cache-first logic - Implemented a basic fallback: - First check the cache - On miss, query DB and update cache 🧠 Implementation Details - Data is stored in key-value format - Keys are carefully structured to be unique and traceable - TTLs (time-to-live) are set optimistically: - Frequently requested static data → longer TTL - Dynamic data → shorter TTL 🚀 The Impact ✅ Reduced load on our primary DB ✅ Faster response times ✅ Enabled us to handle more concurrent users without scaling DB vertically Caching might seem basic — but done well, it can create infra leverage that saves both cost and complexity. Have you implemented caching in your stack? Which tool are you using — Redis, Memcached, or something else? #EngineeringAtInternshala #InfraScaling #CachingStrategy #Redis #Memcached #BackendEngineering #HighTrafficSystems #ScalableArchitecture #DatabaseOptimization #TechInfra #DevOps

22

The Avg. Comp for Meta E5 Level in India is over 75 Lakhs+, including bonuses and stocks, it goes over 1Cr+, and this is just at the Sr. Software Engineer level (5 YOE+) The Avg. Comp for Google E5 Level in India is over 60 lakhs+, including bonuses and stocks, it also goes over 1Cr+, this is the Sr. Software Engineer level (5 YOE+) If I were targeting Sr. Roles are Meta, Google, and Microsoft with my 5+ YOE, this is 1 cheat I would 100% use, created from my own experience. How to use this cheatsheet in an interview? Think in three quick steps: 1. Listen to the problem and label the pattern Example in your head: This is mostly read-heavy with some writes or This is real-time fanout, lots of live updates 2. Pick the closest pattern from the list below 3. Use the lines like this when you speak – First arrow → what kind of systems does this pattern fit – Second arrow → what really matters here – Third arrow → which tools or building blocks to mention – Fourth arrow → how you might summarise it to the interviewer This will help to structure your thinking. By the way, if you are preparing for DSA or system design, try our mock interview tool on Layrs for free:http://layrs.me/interviews 1. Read heavy systems → Fits: feeds, product pages, profiles, dashboards → Focus: fast reads, acceptable staleness, low DB pressure → Tools: cache in front of DB, read replicas, search index, background jobs → How to say it: "This is read heavy. I would put a cache and maybe a search index in front of the main DB, and refresh it with background jobs so most requests never hit the core database." 2. Write heavy, event-driven systems → Fits: logs, clickstream, payments events, audit trails → Focus: durable writes, ordering, handling spikes → Tools: queues or streams, consumers, batching, idempotent handlers, dead letter queue → How to say it: "Here writes are the main thing. I would land everything on a queue or stream first, then process with consumers that are idempotent and can batch work to the database." 3. Real-time fanout systems → Fits: chat, live scores, delivery tracking, notifications → Focus: low latency push, many consumers, avoid constant polling → Tools: websockets or SSE, pub or sub layer, in memory cache, fanout service → How to say it: "This needs real time fanout. I would keep a websocket layer or similar, push updates through a pub or sub channel, and avoid going to the database for every small update." 4. Batch and analytics systems → Fits: reports, BI dashboards, recommendation training pipelines → Focus: huge volume, freshness in minutes or hours, cheap scans → Tools: data lake or warehouse, ETL or ELT pipeline, columnar formats, pre aggregated tables → How to say it: "This is batch and analytics. I would separate the OLTP database from the analytics store, load data in batches, and build pre-aggregated tables for the dashboards." Check the comments as well, please…

237

10 Comments