Aneesh Neelam

Imagine you just joined Google as an SWE. It’s your first week, and you’re overthinking everything. You’re surrounded by world-class engineers, new systems, and an overwhelming urge not to mess up. The pressure to prove yourself is real, and so is the anxiety…so what should you do? Over the years, I’ve moved across orgs, teams, and sometimes, entire companies. Here’s exactly what I did (and still do) to ramp up faster and enjoy the process without letting anxiety win → Don’t let yourself stay stuck. If you’re blocked for more than 30 minutes, ask for help. Share what you’ve tried, show initiative, and intent. → Read way more code than you’re assigned. Dive into related modules, historic PRs, and old design docs. The context you gain helps you spot patterns and avoid mistakes. → Ask about the story behind the system. Find out why things are built a certain way, what’s failed before, and what’s on the roadmap. Understanding the “why” beats memorizing the “what.” → Volunteer for unglamorous work. Take ownership of tests, docs, or nagging integration bugs. This is where you quietly learn the most and build your internal network. → Offer help before you’re an expert. Chime in when you see questions, review PRs, or share a script. Even small contributions get you noticed for the right reasons. → Connect with skip-levels and cross-team leads. Set up short intros to learn about the broader vision and team priorities. You’ll spot opportunities to add value beyond your immediate tasks. → Document what you learn as you go. Share notes, update READMEs, or post quick how-tos in team channels. Your future self and your teammates will thank you. → Shadow someone during incidents or launches. Sit in on debugging sessions or war rooms, even if you’re just observing. You’ll see how senior folks think, react, and communicate under pressure. → Keep a running list of “how did that break?” moments. Every time you see a system fail or a hotfix go live, dig in. Reverse-engineering past problems is the fastest way to understand the architecture. → Show up with curiosity and intent, every day. Don’t just tick off JIRA tickets. Look for the bigger picture. People notice when you genuinely want to learn and contribute, not just “do your job.” Some orgs assign mentors, some don’t. Either way, these habits put you in the driver’s seat. Ramping up is less about brilliance, more about consistent intent. And the ones who learn this early end up leading teams later.

708

52 Comments

Engineering blogs are one of the best ways to learn system design, given how practical they are. I have been dissecting engineering blogs for the last 2 years and posting my explainers on YouTube. While going through my history, I realized I now have 53 blog dissections :) If you are interested in digging deeper into the practical nuances of running systems at scale, give it a watch. I break down complex blogs into simple, visual explanations - no fluff, just real-world systems. Each video focuses on the why behind design choices, not just the what. Here's the playlist - https://lnkd.in/gQ95KnKA I also have explainer series on the following - System design (85+ videos) - Hash table internals - BitTorrent internals - Major outage dissections - Database internals and fundamentals That’s over 220 videos total; all no-fluff and highly practical :) Great for backend engineers or anyone curious about how real-world systems actually work. Many more to come.

621

12 Comments

AWS Lambda is one of those technologies that looks perfect for almost everything. Take a notification service: "Event-driven by nature" "Scales effortlessly" "Pay only when used" On paper, Lambda feels like the obvious choice. But here’s the trap: if the Lambda is cold, the alert goes out seconds late. - A payment failure notification delayed by 3 seconds frustrates customers. - A security alert delayed by 3 seconds undermines trust. That’s the cold start problem. The good news: AWS has solutions today: 1. Provisioned Concurrency keeps functions pre-warmed. 2. SnapStart snapshots initialized runtimes for instant startup. Don’t just ask “Can I put this on Lambda?” Ask “What happens when it’s cold?” Wisdom in engineering often comes from knowing not just what a tool can do, but when it silently breaks your guarantees.

606

90 Comments

Inference is where GenAI bleeds: API bills, 300 ms latencies, idle GPUs. vLLM is how you plug the leak. AI inference cost optimization and enterprise LLM serving start here. Two days ago we proved it at India’s first vLLM meetup at Red Hat, Pune. Outcome (TL;DR): 3 talks | 1 live demo | full hands-on lab. Tech first: - Steve Shirkey: Inference (not just training) is the GenAI battleground; Red Hat AI/Inference Server shows how to ship it at scale. - Me: GenAI inference + LLM fundamentals - Prasad Mukhedkar: Intro to vLLM: paged attention, continuous batching, prefill caching. - Suresh Gaikwad: Live demo of serving & monitoring models on OpenShift AI with vLLM. Hands-on > slides: Prasad spun up GPUs and vibecoded a self-serve UI so folks could grab a GPU and build. We: Installed/configured vLLM and ran vllm serve on an HF model. Tuned engine args, benchmarked, read serving metrics, and wired a Gradio chatbot to infer. People made it work: - Shamsher Ansari kept the discussion grounded by asking insightful questions about real use cases and sharing pain points from his own projects - Avinash Singh pulled a true Red Hatter move, learning while helping others. - Pros and students (Savitribai Phule Pune University and other colleges) brought the energy that made this click Even Yann LeCun says the big spend is shifting to inference, and Andy Jassy expects those costs to tumble as chips improve. Let’s own that curve, not rent it. #vLLM #AIInference #GenAI #OpenSource #EnterpriseAI

117

7 Comments

NEW: Lambda can now send up to 200mb payloads using response streaming! I assume this is mostly directed at LLM inference workloads, where chatbots can stream large amounts of data over the wire as it becomes available.

108

6 Comments

Idempotency isn’t just a consumer problem. Kafka already solves half the equation at the producer. Here’s how Kafka does it? The producer tags each event with a Producer ID and a sequence number. These identifiers get written to the log. If the producer retries because of a failure, the broker sees the same Producer ID + sequence number and rejects the duplicate. The client gets a DUP response. Result: no duplicate publishes. How to enable: - enable.idempotence=true - acks=all - Leave retries high (default OK) - Keep max.in.flight.requests.per.connection<=5 (default is safe with modern brokers) What producer idempotency does not solve? - External side effects (DB writes, HTTP calls, emails). Kafka can’t dedupe those. - Duplicates across different producer identities - Downstream “at-least-once” consumers. If a consumer reprocesses messages and triggers side effects, you can still get dupes. Playbook: 1. Keep enable producer idempotence. 2. Use transactions for exactly-once pipelines. 3. Handle side-effect deduplication at the consumer. Think of it like this: - The producer is the airline system that issues a unique boarding pass (Producer ID + sequence number). - The broker is the gate agent scanning the pass. If the same pass shows up again, it’s rejected as a duplicate. - The consumer is the flight attendant checking you only take one seat (side effects). Idempotency is easy to spell, hard to get right. 😉

660

63 Comments

"Test hotstar.com with 100 users for 2 minutes.” That’s all you type. Just one sentence. No forms. No dashboards. No YAMLs. No SDKs. You lean back, and Ratl awakens. ✨ On the other side, a network of autonomous agents activates. Not bots. Not scripts. A mission control system made of intelligence. 🧠 PlannerAgent understands your intent—performance validation, not just traffic. It quietly maps the blueprint: target, duration, concurrency, goals. 👷‍♂️ CodeGenAgent generates a ready-to-run performance script: headers, auth, payloads, timing, groups—all handled. Clean, production-grade Java. 📈 TrafficModelAgent picks the right pattern: Ramp-up? Constant? Burst? It reads your tone, maps strategy to simulation. 💰 ResourceCalcAgent calculates infra + cost: Pods, CPUs, memory, duration, estimated ₹/$—down to the decimal. 📄 ApprovalAgent presents it all: → What’s being tested → Infra needed → Cost → Options: APPROVE | MODIFY | CLARIFY | CANCEL You reply: “Reduce to 50 users.” 🧠 HumanFeedbackAgent understands, updates the plan—no toggles, just conversation. With one word—APPROVE—the system comes alive. 🛫 ExecutorAgent launches the test. 📡 MonitorAgent checks in every 30s: “Starting…” → “8,500 requests sent…” → “✅ Complete, 99.8% success” 📬 ReportFetcherAgent delivers: → Total requests → Avg latency → Bottlenecks → Recommendations in plain English 🔁 If something breaks—InterruptHandlerAgent takes over: Retries. Logs. Asks. Moves forward gracefully. It even remembers past tests: “Compare to last week.” “Why was this slower?” It knows. It explains. This isn’t automation. This is autonomy. A system that listens. Understands. Plans. Codes. Simulates. Explains. Evolves. All from one sentence. You’re not running a test. You’re commanding a fleet. And the future of load testing responds. Welcome to ratl.ai. Welcome to agent-native reliability. #Ratl #LoadTesting #AutonomousAgents #AIEngineering #LangGraph #AITesting #DevOps #Gatling #InfraSimplified #PerformanceEngineering #ReliabilityEngineering #HumanInTheLoop #FutureOfTesting #AgenticWorkflows

62

4 Comments

Someone mentioned on X "In compute-heavy tasks, avoid using hash data structures unless you have no choice. They are bad for cache performance, especially in NUMA setups." It looked like a very insightful statement - here are some of my random thoughts on it .. Why hash data structures can be bad for compute heavy tasks - 1. Poor Cache Locality - Hash tables involve random memory access due to their hash based indexing, which leads to cache misses and since they often involve intensive processing on large datasets, cache efficiency is crucial. In contrast, data structures like arrays, sorted vectors, or B-trees offer better spatial locality, making them more cache-friendly. 2. In NUMA systems, each processor has faster access to its local memory node. Hash tables often lead to unpredictable memory accesses across NUMA boundaries, causing expensive remote memory fetches. Sequential data structures like arrays or trees allow better memory affinity and can be optimized to stay within the local memory of a CPU core. 3. Branch Misprediction & Indirect Access - Hash tables involve pointer chasing and non-sequential memory lookups, which cause branch mispredictions and degrade instruction level parallelism (ILP). Tight compute kernels (e.g., in image processing or matrix math) rely on predictable loops and minimal indirection to fully utilize SIMD pipelines and modern CPU execution units. However when a problem involves frequent key-based accesses rather than sequential scans, hash tables remain the best option. And there are some alternatives like Flat Hash Maps (e.g., Google's absl::flat_hash_map, Rust's hashbrown using Robin Hood hashing) that can reduce pointer indirection and improve cache locality. In summary: - If your workload is truly compute-bound (e.g., SIMD-based, matrix multiplications, large-scale simulations), avoid hash tables when possible. - If your workload is lookup-heavy, hash tables remain useful but should be optimized for cache locality (e.g., Robin Hood hashing, flat maps).

42

3 Comments