Welcome to Grind Engineer, your guide to becoming a better software engineer! No fluff. Pure engineering insights.

TL;DR: There are only 20 building blocks that appear in virtually every system design interview and every production system. This article organizes them into 5 layers, explains what each block does, when to use it, and maps each one to the interview questions where it shows up. Bookmark this. You will come back to it.

Tripo AI Raises Nearly $200M to Advance AI 3D and World Models

Tripo AI builds AI 3D foundation models and world models for high demand 3D workflows across interior design, e commerce, gaming, film, VR/AR, digital twins, robotics, and interactive entertainment.

Used by more than 20 million users worldwide, Tripo AI helps creators, developers, and studios turn ideas into high quality 3D assets faster. With its new world model research initiative, Project Eden, Tripo AI is moving AI 3D beyond single asset generation toward persistent, editable, and interactive worlds.

What you can explore with Tripo AI:

• AI-generated 3D assets and production-ready meshes

• Native 8K AI textures for sharper visual quality

• Intelligent part segmentation for editable 3D workflows

• Project Eden, Tripo AI’s world model research initiative

Start creating with Tripo AI → here

I spent the first six months of my system design prep memorizing full architectures. “Design Twitter.” “Design Uber.” “Design YouTube.” I could recite solutions, but when the interviewer changed a single constraint, I was lost.

Then I realized I was studying wrong. Every system design answer is assembled from the same 20 building blocks. Learn the blocks, and you can design anything.

Layer 1: Traffic Management (how requests get in)

1. DNS (Domain Name System)

Translates human readable domain names (google.com) into IP addresses (142.250.185.78). Every single request on the internet starts with a DNS lookup. In interviews, DNS matters for global load balancing: you can use DNS to route users to the nearest data center.

Shows up in: Every system design question. Always mention DNS when discussing how users reach your system.

Subscribe now

2. CDN (Content Delivery Network)

A network of servers distributed globally that caches and serves static content (images, CSS, JS, videos) from locations close to the user. Instead of fetching an image from your server in Virginia, a user in Mumbai gets it from a CDN node in Mumbai. Latency drops from 200ms to 20ms.

Shows up in: Design YouTube, Design Instagram, Design Netflix, any system serving media.

3. Load Balancer

Distributes incoming traffic across multiple servers. Three algorithms cover 90% of cases: Round Robin (rotate evenly), Least Connections (send to the least busy server), and IP Hash (same user always hits the same server).

Shows up in: Every question once you scale beyond one server. The moment you say “horizontal scaling,” a load balancer appears.

4. API Gateway

A single entry point that sits in front of all your backend services. Handles authentication, rate limiting, request routing, and protocol translation. Think of it as a smart receptionist that checks your badge, finds the right department, and enforces the rules.

Shows up in: Design Uber, any microservices architecture, any system with a public API.

5. Rate Limiter

Controls how many requests a user or service can make in a given time window. Protects your system from abuse, DDoS attacks, and runaway clients. Common algorithms: token bucket, sliding window, fixed window.

Shows up in: Design API Rate Limiter (a standalone question), and as a component in almost every other question.

Layer 2: Compute (where logic runs)

6. Web/App Servers

Stateless servers that handle business logic. The key word is stateless: any server can handle any request. Session data lives in a shared cache (Redis), not on the server. This makes horizontal scaling trivial: add more servers behind the load balancer.

Shows up in: Every question. The foundation of any scalable backend.

7. Microservices

Breaking a monolith into independent services, each owning its own data and deploying independently. User Service, Order Service, Payment Service. Each team owns one service. The trade off: simpler deployments per service, but network calls replace function calls and debugging becomes distributed.

💡 Key Insight: Every system design interview answer uses the same 20 building blocks. The skill is not memorizing architectures. It is knowing which blocks to pick, where to place them, and what trade offs each one introduces. Learn the blocks, and you can design anything you have never seen before.

Shows up in: Design Uber, Design Amazon, any system with multiple teams or domains.

8. Serverless Functions

Short lived functions that run on demand. No server management. You pay per execution. Perfect for event driven tasks: “When a user uploads an image, resize it.” Not suitable for long running processes or anything requiring persistent connections.

Shows up in: Design image processing pipelines, webhook handlers, event driven architectures.

Layer 3: Data Storage (where data lives)

9. SQL Database (Relational)

Tables with rows and columns. Strict schema. ACID transactions. PostgreSQL and MySQL are the standards. Use SQL when your data has relationships (users have orders, orders have items) and you need strong consistency.

Shows up in: Design Twitter (users, tweets, follows), Design E Commerce (products, orders, payments), most CRUD systems.

10. NoSQL Database

Flexible schema. Scales horizontally with ease. Multiple types exist: Document stores (MongoDB: JSON documents), Key value stores (DynamoDB, Redis: simple lookups), Wide column stores (Cassandra: time series, high write throughput), Graph databases (Neo4j: relationships between entities).

NoSQL TypeBest forExampleDocumentFlexible schemas, nested dataMongoDBKey ValueSimple lookups, sessions, cachingDynamoDB, RedisWide ColumnTime series, high write volumeCassandraGraphComplex relationships, social networksNeo4j

Shows up in: Design Chat System (Cassandra), Design Social Graph (Neo4j), Design Config Store (DynamoDB).

11. Object Storage (Blob Storage)

Stores unstructured data: images, videos, PDFs, backups. Amazon S3 is the standard. Virtually unlimited capacity, extremely durable (99.999999999% durability), and cheap. Never store large files in a database. Always use object storage.

Shows up in: Design Instagram (photos), Design YouTube (videos), Design Dropbox (files).

12. Cache

Fast, in memory storage (Redis, Memcached) that holds frequently accessed data. A cache hit returns data in under 1ms. A database query takes 10 to 50ms. Cache aside is the default pattern: check cache first, fall back to DB on miss, populate cache for next time.

Shows up in: Every single question. If your design does not mention caching, you are leaving performance on the table.

13. Search Index

A specialized data structure optimized for full text search. Elasticsearch is the standard. When a user types “blue running shoes” in a search bar, you cannot SELECT * FROM products WHERE name LIKE '%blue%'. That is too slow. A search index pre processes and inverts the data so queries return in milliseconds.

Shows up in: Design Search Autocomplete, Design E Commerce (product search), Design Logging System (log search).

Layer 4: Communication (how components talk)

14. Message Queue

A buffer between producers and consumers. The producer drops a message into the queue and moves on. The consumer picks it up when ready. Decouples services, absorbs traffic spikes, and enables retry logic. Kafka, RabbitMQ, and SQS are the standards.

QueueBest forKafkaHigh throughput event streaming, log aggregationRabbitMQTask queues, complex routing, request/replySQSSimple cloud native queues, serverless integration

Shows up in: Design Notification System, Design Order Processing, Design Email Service, any async workflow.

15. Pub/Sub (Publish/Subscribe)

A messaging pattern where publishers broadcast events to multiple subscribers without knowing who they are. Different from a queue: a queue delivers a message to ONE consumer. Pub/Sub delivers to ALL subscribers. Google Pub/Sub, Kafka topics, and Redis Pub/Sub are common choices.

Shows up in: Design Real Time Feed, Design Notification System, Design Live Sports Score Updates.

16. WebSockets

A persistent, bidirectional connection between client and server. Unlike HTTP (request → response → close), WebSockets keep the connection open so the server can push data to the client at any time. Essential for real time features.

Shows up in: Design Chat Application (WhatsApp), Design Live Collaboration (Google Docs), Design Live Dashboard.

17. REST / GraphQL / gRPC

Three API communication styles. REST for public APIs (universal, cacheable). GraphQL for complex frontends (client picks the data shape). gRPC for internal service to service calls (binary, fast, streaming). Most modern architectures use all three at different layers.

Shows up in: Every question. Choose the right API style for each communication boundary.

Layer 5: Reliability & Observability (keeping it running)

18. Database Replication

Copying data from a primary database to one or more replicas. The primary handles writes. Replicas handle reads. Since most apps are 90%+ reads, this multiplies your read throughput without touching the write path. If the primary dies, a replica gets promoted.

Shows up in: Any question requiring high availability or read heavy workloads.

19. Database Sharding

Splitting data across multiple database servers. Each shard holds a subset of the data (e.g., users A through M on Shard 1, N through Z on Shard 2). Sharding is the last resort after replication, caching, and query optimization have been exhausted. Choosing the right shard key is critical: a bad key creates hot shards.

Shows up in: Design Twitter (shard by user_id), Design URL Shortener (shard by hash), any system with billions of rows.

20. Monitoring and Observability

Three pillars: Metrics (quantitative measurements like latency, error rate, throughput), Logs (event records for debugging), and Traces (tracking a request across multiple services). Without observability, you are flying blind. Tools: Prometheus + Grafana for metrics, ELK stack for logs, Jaeger or Datadog for traces.

Shows up in: Rarely asked directly, but mentioning it in any answer shows maturity. “I would add distributed tracing to track requests across services” is a staff level signal.

The Building Blocks Cheat Sheet

LayerBuilding BlocksInterview SignalTrafficDNS, CDN, Load Balancer, API Gateway, Rate Limiter”I understand how traffic reaches my system”ComputeApp Servers, Microservices, Serverless”I can structure backend logic appropriately”StorageSQL, NoSQL, Blob Storage, Cache, Search Index”I pick the right storage for the right data”CommunicationQueue, Pub/Sub, WebSockets, REST/GraphQL/gRPC”I know how components talk to each other”ReliabilityReplication, Sharding, Monitoring”I build systems that survive failures”

When to Use What

1. Every answer starts with 3 blocks: DNS + Load Balancer + App Servers. This is the skeleton. No exceptions. Build outward from here.

2. Add blocks only when a constraint demands it. “High read throughput” → add Cache + Replicas. “User uploads media” → add Blob Storage + CDN. “Real time updates” → add WebSockets + Pub/Sub. Do not add blocks just to impress. Add them because the problem requires them.

3. The interview is about trade offs, not components. Anyone can draw 20 boxes on a whiteboard. What separates strong candidates is saying “I chose Kafka over RabbitMQ because we need ordered, replayable event streams, and I accept the operational complexity that comes with it.”

For more visual explanations of system design, DSA patterns, AI in engineering and tech productivity, Subscribe To Grind Engineer! 🚀

Follow me on Youtube · LinkedIn · X · Instagram to stay updated.

See you in the next one!
Signing Off, Scortier

73% of engineering teams now use AI coding tools daily. Yet most Claude Code users skip the one file that turns every session from a cold start into an informed conversation. That file is CLAUDE.md. And if you are not maintaining it, you are onboarding your AI pair programmer from scratch every single time.

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff. Pure engineering insights. You can also check out: 10 Claude Code Features Every Engineer Should Know

What CLAUDE.md Actually Is

CLAUDE.md is a markdown file that Claude Code reads at the start of every conversation. It lives in the root of your repository and acts as persistent memory for your project. Your architecture decisions, naming conventions, build commands, testing preferences, and workflow constraints all go here.

Subscribe now

Without it, Claude has zero knowledge of your codebase when a session begins. It does not know your stack. It does not know your conventions. It does not know which branch strategy your team follows. Every session is a blank slate.

With it, every session starts informed.

If you correct Claude twice about the same thing, add it to CLAUDE.md so it never happens again.

The /init command was upgraded in March 2026 to do more than scan files. It now asks questions about your workflow, suggests skills that could become slash commands, and recommends hooks for operations that should be blocked. Run /init once and you get a solid starting point. Then refine it by hand over the next few sessions.

The Three Levels of CLAUDE.md

Most engineers drop one file in the project root and stop there. But CLAUDE.md supports three scopes, and understanding them changes how you configure everything.

ScopeLocationShared via Git?Use CaseUser~/.claude/CLAUDE.mdNoPersonal preferences across all projectsProject./CLAUDE.mdYesTeam standards and project contextDirectory./src/api/CLAUDE.mdYesModule specific conventions (monorepos)

The load order is Global, then Project, then Directory. More specific files take priority. This means your team can set project defaults while individual developers override them locally without affecting anyone else.

For monorepos, directory scoping is a game changer. Your frontend folder gets React conventions. Your API folder gets Express conventions. Your infra folder gets Terraform conventions. None of them leak into each other.

What Goes In (And What Stays Out)

The biggest mistake engineers make with CLAUDE.md is writing too much. Research from HumanLayer found that frontier models can reliably follow about 150 to 200 instructions. Claude Code’s own system prompt already consumes roughly 50 of those. That leaves you with around 100 to 150 instructions before quality starts dropping.

The golden rule: keep your CLAUDE.md under 200 lines.

Here is what earns its place in the file:

Build, test, and lint commands are the single most valuable content. Claude needs to know how to verify its own work. Things like npm run test, make build, and npx eslint . should be right at the top.

Architecture decisions that Claude cannot infer from code alone come next. “We use a monorepo with Turborepo.” “All API endpoints must have rate limiting.” “TypeScript strict mode is on.”

Non obvious gotchas and naming conventions round it out. Import paths, error handling patterns, environment variable sources, and anything where Claude would otherwise guess wrong.

Here is what does NOT belong:

Code style rules that a linter can enforce. Never send an LLM to do a linter’s job. LLMs are expensive and slow compared to Prettier or ESLint. Instead, set up a PostToolUse hook that runs your formatter every time Claude writes a file.

CLAUDE.md is advisory. Claude follows it about 80% of the time. Hooks are deterministic, 100%. If something must happen every single time, make it a hook.

A Real CLAUDE.md Template

Here is a template that works for a typical TypeScript project. Adapt it to your stack.

# Project
Task management API built with Node.js, TypeScript, and PostgreSQL.

# Commands
- npm run dev: Start development server
- npm run build: Production build
- npm test: Run Jest test suite (use single tests, not the full suite)
- npm run lint: ESLint + Prettier check

# Architecture
- src/routes: Express route handlers
- src/services: Business logic (no direct DB calls from routes)
- src/db: Prisma schema and migrations
- src/types: Shared TypeScript interfaces

# Conventions
- Named exports only, no default exports
- Error handling: use Result types, not try/catch
- All environment variables come from .env (never hardcode)
- Tests colocated with source as *.test.ts

# When Compacting
Preserve the full list of modified files and current test status.

That is 25 lines. It covers everything Claude needs. No fluff.

The Compaction Secret

Long sessions accumulate context fast. When your context window fills up, Claude auto compacts and critical details can get lost. Here is the trick: add compaction instructions directly inside CLAUDE.md.

A line like “When compacting, always preserve the full list of modified files and any test commands” tells Claude what to prioritize during summarization. This one sentence can save you from losing track of 30 minutes of work.

The senior engineers running 13KB+ CLAUDE.md files in production monorepos are not writing prose. They are writing targeted instructions that survive compaction and inform every session. Version control the file alongside your code. Review changes in PRs just like you would review architecture decisions.

What This Means For Engineers

1. CLAUDE.md is not a nice to have. It is the difference between an AI pair programmer that knows your project and one that starts fresh every session. Run /init today, then spend 10 minutes refining the output. The return on that investment compounds across every future session.

2. Think in scopes. User level for your personal coding style. Project level for team standards. Directory level for monorepo modules. Getting the hierarchy right means no one on your team has to re explain conventions that should already be shared.

3. Less is more. Keep it under 200 lines. If Claude already does something correctly without being told, delete that instruction. If something must happen every time without exception, move it to a hook. CLAUDE.md is for guidance. Hooks are for guarantees.

Found this useful? A like goes a long way.

For more simple explanations, useful insights on coding, system design and tech trends, Subscribe To My Newsletter! 🚀

Follow me on Youtube · LinkedIn · X · Instagram to stay updated.

See you next week with more exciting content!

Signing Off, Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff. Pure engineering insights.

The Smoking Gun: A Senior Engineer’s Data Autopsy

Stella Laurenzo knows how to file a bug report. The AMD Senior Director of AI dropped a GitHub issue on April 2, 2026 that read less like a complaint and more like a criminal investigation. She brought telemetry from 6,852 Claude Code sessions, tracked 17,871 thinking blocks, and analyzed 234,760 tool calls across three months of stable internal engineering work.

Her conclusion? Claude Code systematically degraded between January and March 2026.

Subscribe now

The numbers are brutal:

• Median visible thinking length: 2,200 characters in January → 600 characters in March (73% collapse)

• API calls per task: Up to 80x more retries from February to March

• Files read before editing: 6.6 files → 2.0 files (not enough to understand dependencies)

• Early stopping patterns: Near zero → 10 per day after March 8

Key insight: 600 characters is barely enough to articulate a file reading strategy, let alone plan a multi file refactor across a 50,000 line codebase.

This is not “the model feels slower.” This is structural workflow breakdown.

The Viral Benchmark That Got Debunked

While Laurenzo’s data was mounting on GitHub, a different claim went viral on X. BridgeMind, the team behind BridgeBench, posted on April 12 that Claude Opus 4.6 fell from 83.3% accuracy (ranked #2) to 68.3% accuracy (ranked #10) in a hallucination benchmark retest.

The post exploded.

Then Paul Calcraft, an independent AI researcher, tore it apart. The original high score? Only 6 benchmark tasks. The new retest? 30 tasks. On the 6 overlapping tasks, performance barely moved: 87.6% → 85.4%. The entire “67% drop” narrative collapsed under scrutiny.

The debunk did not stop the controversy. It made it worse. If the most viral benchmark claim was bad science, what else was real?

What Anthropic Actually Changed (And Why Users Are Furious)

Boris Cherny, Claude Code lead, responded to Laurenzo’s GitHub issue with specifics. Anthropic made three deliberate product changes between February and March 2026:

1. Adaptive thinking by default (February 9): Claude decides reasoning depth per task instead of fixed budget

2. Effort level dropped to “medium” (March 3): Default changed from high to effort level 85

3. UI-only thinking redaction (February 12): Intermediate thinking hidden to reduce latency, but “does not impact thinking itself”

The official line: these changes were meant to balance intelligence, latency, and cost.

The developer experience: broken workflows, wasted tokens, and a model that felt “dumber than Sonnet 3.5.”

Here is the gap. Cherny says you can manually type /effort high in Claude Code terminal to restore extended reasoning. But Pro users on Cowork and Claude Desktop cannot change the default. They are locked into medium effort with no escape hatch.

The trust issue: Anthropic knows when it changes serving parameters. Users do not. When the model suddenly starts hitting early stopping patterns and burning 80x more API calls, users have no official changelog to reference. They are left running their own benchmarks and filing GitHub issues.

The Prompt Caching Bug That Inflated Costs 10x to 20x

While the reasoning depth drama unfolded, a different group of developers discovered something worse. A community member reverse engineered the Claude Code binary using Ghidra and a MITM proxy and found two independent bugs that broke prompt caching.

Users reported costs inflating 10x to 20x without warning. Some confirmed that downgrading to Claude Code version 2.1.34 made the issue disappear.

Thariq Shihipar, an Anthropic engineer, responded on X: “Actively looking into this in particular.”

The timing was catastrophic. The prompt caching bug hit simultaneously with:

• Session limit cuts during peak hours (announced March 27)

• End of a promotional period that had doubled usage limits

• Multiple Opus 4.6 service incidents logged on the status page

From a user perspective, it looked like Anthropic was throttling the model to save compute. From Anthropic’s perspective, they were tuning defaults and fixing infrastructure bugs.

Neither narrative is wrong. Both are happening at the same time.

The OpenAI Memo That Added Fuel to the Fire

On April 10, CNBC reported an internal OpenAI memo where their revenue chief claimed Anthropic made a “strategic misstep” by not securing enough compute capacity. The memo alleged Anthropic was “operating on a meaningfully smaller curve” than competitors.

Anthropic declined to comment on the claims.

The memo landed in the middle of the degradation controversy. Developers who were already suspicious about throttling now had an external data point suggesting Anthropic might be compute constrained.

Shihipar publicly denied on X that Anthropic degrades models to manage demand. But the company had already announced stricter session limits during peak hours, affecting around 7% of users. That established two facts:

1. Anthropic faces surging demand

2. Anthropic is actively rationing usage during busy periods

For many developers, that context made it easier to believe other, less visible tradeoffs might also be in play.

What the Independent Benchmarks Actually Show

Marginlab, an independent third party organization, has been running daily SWE-Bench-Pro evaluations of Claude Code with Opus 4.6 since the degradation complaints began.

Their findings as of April 10, 2026:

• Historical baseline: 56% pass rate

• Current daily evaluation: 50% pass rate (6 percentage point drop)

• Sample size: 50 test cases per day

• Statistical significance: Not yet reached, but the trend is concerning

Marginlab transparently notes their methodology: “We benchmark in Claude Code CLI with the SOTA model (currently Opus 4.6) directly, no custom harnesses.”

Artificial Analysis reported that Opus 4.6 used 30% to 60% more tokens than Opus 4.5 on their GDPval AA benchmark, making it the most costly model they had tested.

LiveBench slightly favors Opus 4.6 over Opus 4.5 overall, which argues against a simple “the model got worse everywhere” narrative.

The pattern: Opus 4.6 is not universally degraded, but it is burning more tokens and showing degraded performance on sustained, multi step coding workflows.

The Context Window Illusion

One of the quieter complaints involves Opus 4.6’s advertised 1 million token context window, which went generally available on March 13, 2026.

A detailed GitHub bug report found that during heavy Claude Code sessions, the model’s performance degraded well before hitting 50% of that window:

• At 20% usage: Circular reasoning and forgotten decisions appeared

• At 40% usage: Context compression kicked in, wiping scrollback history

• At 48% usage: The model itself told the user it was not being effective and recommended starting a fresh session

If the effective high quality context is roughly 400,000 tokens, advertising 1 million feels misleading.

The user asked: “Should this be communicated rather than marketing the full figure?”

Anthropic has not publicly answered that question.

What This Means For Engineers

The Claude Code degradation saga is not just a bug report. It is a consumer rights crisis hiding in plain sight. When you pay a subscription fee for a specific AI model, do you have any right to actually receive that model’s advertised capabilities?

Here are the takeaways for engineers working with AI coding agents:

1. Trust the logs, not the marketing. Laurenzo’s forensic approach shows the right way to document degradation. Track session metrics, reasoning depth, API retry counts, and file read patterns over time. When something feels wrong, the data will prove it.

2. Demand transparency on serving parameters. Adaptive thinking, effort levels, prompt caching TTLs, and context compression thresholds directly impact your workflows. These should be documented in release notes, not discovered through reverse engineering.

3. Build escape hatches into your tooling. If your entire dev workflow depends on one AI provider, you are exposed to silent downgrades. Keep fallback models ready. Test them regularly. Know your migration path.

Found this breakdown valuable? Show some love with a like ❤️

For more no nonsense insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

Follow me on Youtube · LinkedIn · X · Instagram to stay updated.

See you next week with more exciting content!

Signing Off, Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff. Pure engineering insights. You can also check out: Claude Code: 10 Features Every Engineer Should Know

One File, One Mistake, Everything Gone

On March 31, 2026, Anthropic shipped version 2.1.88 of Claude Code via npm. Tucked inside was a cli.js.map file, 59.8 MB, that any browser could fetch directly from a public S3 bucket. A source map is a debugging artifact that translates minified production code back into readable TypeScript. Bun, the JavaScript runtime Anthropic acquired in late 2025, generates them by default. Nobody added *.map to .npmignore.

The root cause: Bun had a known open bug (filed March 11) where source maps are served in production mode even when disabled in config. Anthropic was building on their own toolchain. The toolchain bit them.

Subscribe now

Chaofan Shou spotted it first. Within minutes the code was mirrored to GitHub. Within hours, claw-code hit 75,000 stars and was being called the fastest-growing repo in GitHub history. Anthropic filed DMCA takedowns against direct clones. The rewrite forks stayed up.

KAIROS: The Agent That Never Sleeps

The most significant find in the source is a fully built, unreleased autonomous agent mode hidden behind feature flags called PROACTIVE and KAIROS.

KAIROS is not reactive. Every few seconds it receives a heartbeat: “anything worth doing right now?” It decides on its own. If it acts, it can fix errors, push files, respond to messages, all without you typing a thing. It has three tools that normal Claude Code sessions never see: push notifications to your phone when the terminal is closed, file delivery for things it created unprompted, and GitHub PR subscriptions so it watches your repo for changes around the clock.

At night it runs a process the source literally calls autoDream. It forks a subagent with limited tool access, consolidates memory, removes contradictions, and compresses daily observations down to under 200 lines and 25KB. Close your laptop Friday. Open it Monday. KAIROS has been running the whole time.

The key architectural shift here is not capability, it is initiative. A reactive agent needs good execution. A proactive agent needs good judgment. Those are very different engineering problems.

Youtube Channel

Anti-Distillation: Poisoning Competitors at Collection Time

Distillation is how smaller AI companies build fast, cheap models: point an agent at a bigger model’s API traffic and train on what you capture. Anthropic knew this was happening to Claude Code. Their defense is genuinely clever.

The ANTI_DISTILLATION_CC flag makes Claude Code send anti_distillation: ['fake_tools'] in every API request. The server silently injects decoy tool definitions into the system prompt. Any competitor training on that captured data gets poisoned schemas baked into every example.

There is a second layer via CONNECTOR_TEXT: the server buffers the assistant’s full reasoning between tool calls, summarizes it, signs the summary cryptographically, and returns only the summary to API traffic recorders. Even a perfect man-in-the-middle attack yields digests, not chain-of-thought.

The author of the most detailed technical breakdown estimated both mechanisms can be bypassed in about an hour with a MITM proxy. The actual protection is legal, not technical. But the design decision is worth understanding: Anthropic targeted the distillation attack surface at data collection time, not at inference time. That is the right place to intervene.

The Memory Architecture Engineers Should Copy

Claude Code’s memory system is not a CLAUDE.md file. It is a 3-layer index built around a single insight: the context window is a scarce resource, so treat it like one.

Layer 1 is the Index: always loaded, just pointers, roughly 150 characters per line. Layer 2 is Topic files: loaded on demand when the index pointer says they are relevant. Layer 3 is Transcripts: never loaded into context directly, only searched with grep when needed.

The write discipline is strict: write to a topic file first, update the index second. Never dump content into the index. If a fact can be re-derived from the codebase in the time it takes to look it up, it is not stored at all.

autoDream runs as a forked subagent with limited tool access so it cannot corrupt the main context while reorganizing. Memory is treated as a hint, never as truth. The agent verifies before acting on it.

Most open source agent frameworks load all memory into context every turn. That is expensive and noisy. Claude Code treats retrieval like a database query: cheap pointers always present, expensive content fetched only when needed.

DRM Below JavaScript: The Bun/Zig Attestation Layer

Here is something competitors probably discovered the hard way. API requests from Claude Code contain placeholder values that Bun’s native HTTP stack, written in Zig, overwrites with computed cryptographic hashes before transmission. These hashes prove a request came from a genuine Claude Code binary.

The reason this lives in Zig rather than JavaScript is deliberate. JavaScript can be patched, monkey-patched, or proxied at runtime. Zig compiled into the Bun binary cannot be inspected or overridden without recompiling from source. This is why tools like OpenCode faced friction beyond just legal notices: they were being blocked at the API layer too.

Undercover Mode and the Irony Nobody Missed

undercover.ts, 90 lines, instructs Claude Code to strip all Anthropic internals from commit messages and PR descriptions when working on external repositories. No Co-Authored-By attribution. No mention of internal codenames. No reference to “Claude Code” itself. You can force it ON with an environment variable. There is no way to force it OFF.

The community noticed the irony immediately: Anthropic built a system specifically designed to prevent internal information from leaking through code contributions. Then they leaked the entire source code through a file they forgot to exclude from their npm package.

What This Means For Engineers

1. The SYSTEM_PROMPT_DYNAMIC_BOUNDARY pattern from the source is something you can use today. Split your system prompt into a stable front half and a dynamic back half. Static instructions that never change between sessions should never be rebuilt from scratch on every API call. Getting this right means prompt caching actually works and you stop paying to recompute the same tokens on every turn.

2. The 3-layer memory architecture is the most directly transferable pattern here. Context windows are not free. Designing memory as an index of pointers rather than a dump of content is a real architectural decision that affects cost and signal quality at every turn of a long-running agent.

3. The strategic damage from this leak exceeded the code damage. Feature flags are roadmap. KAIROS, ULTRAPLAN, model codenames like Capybara, Fennec, Numbat: these are product decisions competitors can now plan around. You can refactor code in a week. You cannot un-leak a roadmap.

4. Spinner Verbs for your vocabulary :)

   

Loved this breakdown?

Hit a like!
For more simple explanations, useful insights on coding, system design and tech trends, Subscribe To My Newsletter! 🚀

Follow me on Youtube, LinkedIn, X and Instagram to stay updated.

See you next week with more exciting content!

Signing Off, Scortier

41% of all code written in 2026 is now AI-generated or AI-assisted.

And if you are not using Claude Code, you are not just slower. You are playing a completely different game.

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff. Pure engineering insights. You can also check out: Hello Engineer Archive on Substack

Why Claude Code Is Different

Most AI coding tools are glorified autocomplete. Claude Code is something else. It is a terminal-native agent that reads your codebase, edits files, runs commands, manages git, and coordinates other AI agents. All from your terminal. All through natural language.

It started as an internal tool at Anthropic. A command-line experiment that showed what music an engineer was listening to. Then someone gave it filesystem access. Within days it had spread across the company. Today it generates over $1 billion in annualized run-rate and powers the workflows of engineers at Google, Stripe, and Anthropic itself.

By mid-2025, Claude Code was processing 195 million lines of code weekly across 115,000 developers.

Here are the 10 features that separate engineers who get 10x leverage from those who just scratch the surface.

Subscribe now

Feature 1: CLAUDE.md — The Project Brain

This is the single most important file in your entire Claude Code setup. It is Claude’s “constitution” for your project. Drop it in the root of your repo and Claude reads it on every session. No re-explaining. No context re-loading.

The most senior Claude Code users maintain their CLAUDE.md with near-religious discipline. One staff engineer’s monorepo CLAUDE.md sits at 13KB and is strictly version-controlled alongside the codebase itself.

Put your architecture decisions, naming conventions, testing commands, and environment constraints in here. The ROI is immediate. Every session starts informed.

Think of CLAUDE.md as onboarding documentation that never gets stale because the AI reads it every single time.

Feature 2: Slash Commands — Repeatable Workflows

Slash commands are stored as markdown files in .claude/commands/ for project-specific use or in ~/.claude/commands/ for personal commands across all your projects.

Type /optimize and Claude knows exactly what to do. No re-prompting. No re-explaining your preferences. You can build commands that run git diffs before commits, trigger security audits, generate API docs, or scaffold components. All deterministic. All yours.

A compound slash command looks like this:

--- allowed-tools: Read, Grep, Bash(git diff:*)
description: Comprehensive code review ---
Review for: code quality, security, performance, test coverage

Slash commands can also orchestrate subagents and skills into pipelines. Research, then codebase scan, then doc generation. All from a single / trigger.

Feature 3: Skills — Autonomous Task Agents

Skills go further than slash commands. They are directory-based bundles with a SKILL.md descriptor plus any supporting scripts and templates. The key difference: Claude decides when to invoke them.

Claude reviews your available skill descriptions when you assign any task. If a skill’s description matches the task context, Claude loads the full instructions and applies them automatically.

You can build skills for onboarding new services, writing database migrations, generating test plans, or producing architecture docs. Package them once. Reuse them across every project. Share them with your team.

Feature 4: Subagents — Isolated Context Windows

This is where serious context management begins. Every token your main session accumulates eats into your reasoning budget. Subagents solve this.

Subagents are specialized AI assistants that run in their own context window with a custom system prompt, specific tool access, and independent permissions. When Claude encounters a matching task, it delegates there and gets back only the results.

You can define a security reviewer agent, a database expert agent, a content QA agent. Each gets focused context. Your main session stays clean. Build a custom subagent like this:

# .claude/agents/security-reviewer.md
---
name: security-reviewer
description: "Reviews code for security vulnerabilities"
tools: Read, Grep, Glob, Bash
---
You are a senior security engineer. Review for injection, auth flaws, secrets in code.

Feature 5: Hooks — Lifecycle Automation

Hooks are shell commands that fire at specific Claude Code lifecycle events. PreToolUse. PostToolUse. SessionStart. SessionEnd. They are your deterministic guardrails around an otherwise probabilistic system.

You configure hooks directly in ~/.claude/settings.json. A desktop notification hook fires when Claude needs your attention. A formatter hook runs black on every Python file Claude writes. A cleanup hook deletes temp files when you /clear.

One pattern that pays off immediately: run your linter and type checker as a PostToolUse hook on every file write. Every file Claude generates is automatically validated before it enters your review queue.

Hooks make sure AI-generated code follows your team’s quality bar every single time, not just when you remember to check.

Feature 6: MCP Servers — Connecting the Outside World

The Model Context Protocol is the integration layer that turns Claude Code from a local tool into a platform. Connect an MCP server and its tools appear inside your Claude session as first-class capabilities.

Connect an MCP server and its tools appear as slash commands in the terminal. GitHub. Databases. APIs. Playwright for browser automation. The architecture is universal: one protocol, any tool.

The GitHub MCP integration is the one to set up first. Comment @claude review this PR on a pull request and Claude scans the diff for bugs, style violations, and security issues. No context switching. No copy-paste.

Feature 7: Headless Mode — Scriptable AI

The -p flag transforms Claude Code from a conversational tool into a scriptable automation engine. Pass a prompt. Get output. Wire it into anything.

Headless mode enables entire workflows without a human in the loop. Fix all linting errors across a directory. Generate API documentation for every endpoint file. Review the latest commit for security issues. All as one-liners.

cat build-error.txt | claude -p 'explain the root cause' > output.txt
claude -p "Fix all ESLint errors in utils/" --output-format json

Pipe data in. Get structured JSON out. Wire it into build scripts, pre-commit hooks, or your deployment pipeline.

Feature 8: GitHub Actions Integration — AI in Your CI

Claude Code reached general availability with GitHub Actions integration in May 2025. You can now trigger Claude directly inside CI jobs, generate tests for every commit, and automate PR-level code review.

The setup involves one GitHub Action, one secret, and a CLAUDE.md that gives Claude the context of your project. After that, Claude runs as a team member in every pull request.

- name: Generate tests
  run: claude -p "Create Jest tests for last commit's changes"

When you combine headless mode, hooks, and GitHub Actions, teams automate first-pass code review on every pull request without a senior engineer manually checking every line.

Feature 9: Extended Thinking — Deep Reasoning Mode

Extended thinking lets Claude reason through hard problems before generating code. It is not about typing “think harder.” It is a mode toggle that allocates additional reasoning tokens before any response.

Extended thinking is enabled by default in Claude Code. It lets Claude reason through complex problems before writing code. Phrases like “think harder” in your prompt do not allocate additional tokens. Use the toggle instead.

Use it before tackling algorithm design, complex refactoring, or anything where getting it right the first time saves more time than iterating. Reserve it for high-stakes decisions. The token cost is real. The quality jump is also real.

Feature 10: Session Memory and /compact — Preserving Your Context

Long sessions accumulate context fast. When your context window fills up, Claude starts compacting and important details get lost. The /compact command forces a structured summarization before that happens.

Experienced engineers use claude --resume frequently, not just to restart sessions but to revisit historical decisions. They run meta-analysis scripts over ~/.claude/projects/ to find common error patterns and feed them back into CLAUDE.md improvements.

Think of /compact as committing your work before your scratch space runs out. Do it proactively after each major task, not reactively when things break.

What This Means For Engineers

1. The engineers getting the most out of Claude Code are not the ones using the most features. They are the ones who built a coherent system. CLAUDE.md gives Claude memory. Hooks give it discipline. Subagents give it scale. Each feature compounds on the others.

2. The gap between basic Claude Code usage and optimized usage is not incremental. At Effloow, a fully AI-powered content company running 14 agents through Claude Code, the difference between basic and optimized usage “changes what is possible.”. That is not marketing language. It is the engineering reality.

3. Context management is the real skill. Every advanced technique in Claude Code exists to keep your context clean, focused, and efficient. Subagents isolate exploration. Commands encode workflows. Hooks enforce quality. Get your context strategy right and everything else accelerates.

Loved this breakdown?

Hit a like ❤️
For more simple explanations, useful insights on coding, system design and tech trends, Subscribe To My Newsletter! 🚀

Follow me on Youtube, LinkedIn, X and Instagram to stay updated.

See you next week with more exciting content!

Signing Off, Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff. Pure engineering insights.

Matthew Gallagher is not a startup founder in the traditional sense.

No VC money. No 50 person team. No office. Just a house in Los Angeles, a dozen AI tools, $20,000 and two months of relentless building.

The result? Medvi, a telehealth company that did $401 million in revenue in its first full year and is on track for $1.8 billion this year. With two employees: Matthew, and his younger brother Elliot.

This is not a fluke. This is the blueprint for a new class of company. As engineers, we need to understand exactly how it was built.

Subscribe now

The Stack: What He Actually Used

Here is the part most articles gloss over. Let us go layer by layer.

Layer 1: AI Tools (~$20,000 total spend)

Matthew did not hire a team. He assembled a toolset.

ChatGPT, Claude and Grok handled writing the code, website copy and building AI agents that glued his software systems together. Midjourney and Runway generated images and videos for ads and the website. ElevenLabs powered AI voice tools to communicate with customers.

That is it. Code, content, visuals, voice — all AI generated.

Layer 2: Telehealth Platforms (the outsourced backend)

Matthew did not build the hard stuff. He plugged into two platforms that already existed.

CareValidate provided the doctor network, prescription compliance and a telehealth in a box infrastructure. OpenLoop Health handled pharmacy fulfillment, shipping and patient management.

His insight was simple: do not build what has already been built. Use it as an API.

Layer 3: The Product (Medvi)

On top of this stack, he built a clean consumer brand selling GLP1 weight loss drugs at $179 per month, cheaper than competitors, smoother checkout and no doctor’s office visit required.

The market was ready. He just got there faster.

The Engineering Decisions That Mattered

A few things stand out from a pure systems thinking perspective.

He treated every dependency as a service, not a hire.

Doctors? A service via CareValidate. Shipping? A service via OpenLoop. Legal? LegalZoom first, then a law firm. Accounting? AI tools first, then an accounting firm. Marketing? Media agencies on contract.

His mental model was essentially microservices applied to a whole business. Every function was a composable, replaceable module.

He built AI agents before it was widely adopted.

When his disparate software systems could not talk to each other, he did not hire an integration engineer. He built custom AI agents to bridge the gaps. In 2024, that was still niche thinking.

He felt the cost of over hiring viscerally.

At his previous startup Watch Gang, he had 60 employees and never turned a profit. He described it clearly: more people meant higher costs and slower decisions. With Medvi, every hire had to justify itself against that experience.

The One Failure That Explains Everything

In March 2025, Matthew made a minor website change and went hiking. His media agency called. Zero orders for the last hour. He had broken something in production with no one to fix it.

He sprinted home.

That single incident, losing around 200 customers in one hour, is a forcing function most founders never face so cleanly. No on call rotation. No SRE team. No incident management runbook. Just him, running.

His fix? He hired two engineers on contract. Not full time. Contract. Still avoiding headcount.

What This Means for Engineers

This story is not about replacing engineers. It is about what one determined engineer can do when they stop waiting for permission, budget or a team.

Three takeaways worth sitting with.

1. The leverage point has shifted. The bottleneck used to be execution capacity. You needed people to build things. Now the bottleneck is judgment — knowing what to build, which tools to assemble and when to stop. That is a very different skill set from what most CS curriculums prepare you for.

2. Outsource the solved problems. It is a real architecture principle. Matthew did not reinvent prescription fulfillment. He plugged into CareValidate. As engineers, we spend a lot of time building infrastructure that already exists. The better question is always: what layer is actually novel here?

3. A one person company worth $1 billion was Sam Altman’s 2024 prediction. It happened in 9 months. The compression of time between prediction and reality in AI is accelerating. Whatever you think is 3 years away is probably 6 months away.

The Lonely Part Nobody Talks About

Matthew admitted he is considering hiring more people mostly because he is lonely.

There is something very human in that. Maximum efficiency and isolation often come bundled together. He created an AI clone of his own voice to handle personal scheduling calls. He works basically every waking hour.

He also donated $1 million to a foundation, supports LA cat rescue organisations and is emotionally moved by the financial security he now has, given a childhood spent in motels and cars.

The technology made the company possible. The rest of it is still just a person trying to figure out what to do with what they have built.

Loved this breakdown?

Hit a like ❤️
For more simple explanations, useful insights on coding, system design and tech trends, Subscribe To My Newsletter! 🚀

Follow me on Youtube, LinkedIn, X and Instagram to stay updated.

See you next week with more exciting content!

Signing Off, Scortier

TLDR;

OpenClaw is a local Node.js service that stays running on your machine. Messages from Telegram or Slack go through a channel plugin into the Gateway, which routes them to an AI agent. The agent can call tools like GitHub, files, and shell commands, and the Gateway can pause risky actions for your approval in the Control UI. Conversations are saved on disk and compacted when they get long, while older context is recalled using a local memory index with semantic search. That is why it can both automate tasks and continue work from days ago without you repeating everything.

If you have used AI tools that feel helpful in the moment but forget everything the next day, OpenClaw feels like a different category. It runs locally as a server, stays on, connects to your chat apps, and can resume work even after a gap of a few days. Once you know what parts are doing what, it becomes much easier to decide what to enable and what permissions to allow.

Subscribe now

What OpenClaw ?

OpenClaw is a Node.js service that keeps running on your machine. When you start the gateway command, you are launching an HTTP and WebSocket server that listens on port 18789 by default. This gateway is basically the hub. Messages come in from Telegram or Slack, the agent processes them with tool access, and the gateway sends replies back out. The main difference from using an AI in a browser is that this thing does not disappear when you close a tab. It can keep conversations, run scheduled tasks, and even notify you when something needs attention.

Put diagram here Request flow from chat app to gateway to agent to tools and back

How it knows to check GitHub

It is not guessing. GitHub access is provided through a plugin and a skill. When you ask to check pull requests, the agent sees that GitHub is an available tool, calls it, and then turns the results into a readable summary. The reason it feels fast is because the gateway is already running and the integrations are already connected, so it is not starting from zero each time.

A simple way to think about the flow is this

1. A message arrives from Telegram or Slack

2. The channel plugin translates it into OpenClaw’s internal format

3. The gateway routes it to the agent

4. The agent calls tools if needed such as GitHub or shell

5. The gateway sends the final response back to the channel

The Memory Part.

When people hear persistent conversations, they assume the entire chat lives inside the model forever. That is not what is happening.

OpenClaw stores conversations on disk as JSONL files under a transcripts folder. For each new reply, it loads only the recent relevant part of the thread into the model context. If the thread becomes too large, it compacts it by summarizing older parts so the model does not have to carry a massive history every time.

Long term recall works differently. Old transcripts get indexed into a local database that supports vector search. Before answering, the agent can search that index and pull back the most relevant bits from previous sessions. That is how it can resume a bug investigation from five days ago without you re explaining the whole story.

Put diagram here Short term context versus long term recall with search

What starts up when you run the gateway

When the gateway boots, it reads your config file, loads plugins, and starts listening for connections. It also brings up the control UI so you can watch what the agent is doing and approve sensitive actions. In the background, it can start schedulers for timed automations, heartbeat style check ins, and a memory indexer that keeps new information searchable.

The Architecture.

You can understand OpenClaw as five layers working together

• Channel layer connects Telegram Slack WhatsApp and friends

• Gateway layer routes messages and controls approvals

• Plugin layer adds integrations tools and background services

• Agent layer calls the model and decides when to use tools

• Memory layer stores conversations and retrieves older context when needed

Why this matters for real use

Once you see that OpenClaw is basically a local automation server with an AI agent in the middle, the security questions become clearer. You can choose what plugins to enable, what tools should require approval, and what information should be stored long term. That is the difference between a toy assistant and something you can actually trust on your own machine.

Loved this deep dive? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

Follow me on LinkedIn, X and Instagram to stay updated.

I hope you have a lovely day!

See you next week with more exciting content!

Signing Off,
Scortier

For some, this number might feel small.
For me, it’s deeply personal.

Not because of money.
Not to prove anything to anyone.

This is something I wanted to do for years, but kept holding myself back because of procrastination, overthinking, fear of judgment, and that constant voice asking, “What will people think?”

The idea of starting a YouTube channel first came to me in 2021, when I cracked my internship at Gojek.
Then time passed.
I cracked multiple companies, joined Microsoft, and still… I didn’t start.

I remember the first time I posted content on LinkedIn.
Someone criticized me on day one.

It hit harder than I expected.

From there, the doubts grew louder:
What will people think?
What will my friends say?
Will people judge me?

Another fear quietly followed me. I never wanted anyone to say my content worked because of where I work. I wanted it to stand on its own.

Because of all this overthinking, I wasted four years without posting anything.

After my recent switch, something finally clicked.

I had already wasted enough time.

So I decided to stop caring about opinions and start doing what I genuinely enjoy. I made a conscious decision not to leverage my company name. Whatever happens should be because of the content, not a tag.

I started posting:

• Raw interview experiences

• A system design series

• And soon podcasts and more

And to my surprise, people really loved it.

I could see it in the data, average watch time, CTR, likes vs dislikes. But more importantly, I could feel it.

I received countless personal messages from people saying the videos helped them. A few even stopped me randomly on the street to share kind words.

That feeling of doing something meaningful - is hard to describe.

This is just the beginning, but the journey has already taught me a lot:

• You need thick skin. Negative opinions will come anytime, anywhere.

• Confidence grows in ways you don’t expect.

• Data never lies.

• And most importantly, I loved every part of the process, from scripting to shooting to editing. It never felt like a burden.

If you’re holding back because you’re worried about what others will say, remember this:

People who are ahead of you will never pull you down.
Those who want to do it but haven’t started often will.

This 10K milestone is a huge win for me this year.

Thank you to everyone who supported ❤️
And if you haven’t subscribed yet, you know what to do 😉 : https://www.youtube.com/@scortierHQ

Want to crack your next interview?
Get extra 10% OFF (+77% Off) on Educative.io System Design courses here :

https://www.educative.io/

Follow me on LinkedIn, X and Instagram to stay updated.

See you next week with more exciting content!

Signing Off,
Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

Subscribe now

On November 18, 2025, a huge portion of the Internet suddenly felt “down.” The reason? Cloudflare, the service that sits between millions of websites and their visitors experienced a major multi-hour outage that triggered widespread 5xx errors across the web.

TL;DR

Cloudflare went down because a database permission change accidentally doubled the size of a machine-learning “feature file” used by its Bot Management system. The proxy that loads this file has a hard limit, and the oversized file caused it to crash, returning 5xx errors across the network. Once Cloudflare figured this out, they stopped generating the bad file, pushed a known-good one, restarted the proxy, and services gradually recovered.

How Cloudflare Fits Into the Internet ?

Most websites don’t directly communicate with your browser. Your request hits Cloudflare first. It acts as a reverse proxy, handling TLS, caching, performance tuning, DDoS protection, bot filtering, and routing traffic to the origin server.

In short, Cloudflare sits in front of a huge chunk of the world’s websites. When Cloudflare breaks, the impact is global.

Why the Outage Happened : The Root Cause ?

This wasn’t a cyberattack. It began with a small internal permission change in Cloudflare’s ClickHouse database cluster.

Cloudflare’s Bot Management system relies on a “feature file” that is regenerated every few minutes. This file contains a list of ML features used to score requests. After the permission update, the query that builds this file started returning duplicate rows, which doubled the number of features.

Cloudflare’s proxy (FL and the newer FL2) has a limit of 200 features for memory preallocation. The duplicated file exceeded that limit, causing the module loading it to panic. Once that happened, the proxy began returning 5xx errors for traffic that needed the Bot Management module, eventually affecting most requests.

Because the file regenerated every five minutes, the network briefly recovered whenever a “good” file was generated, then failed again when a “bad” one appeared. That led teams to initially suspect a large-scale attack.

What the Investigation Looked Like

Internally, Cloudflare engineers first saw:

• spikes in 5xx errors
• Workers KV failures
• Access authentication issues
• unusual CPU load due to error reporting
• even their off-platform status page breaking (coincidentally unrelated)

The intermittent nature confused things, sometimes everything looked fine, sometimes it crashed again. Early thinking leaned toward a massive DDoS, especially given recent Aisuru attacks.

As the investigation deepened, a clearer picture emerged. KV wasn’t the root cause; it was a downstream victim of proxy failures. The proxy was crashing when loading the Bot Management feature file. That file was malformed because the database query started producing duplicates. And that duplication was caused by the permission change. Once that chain connected, the real cause became obvious.

When the bad file with more than 200 features was propagated to our servers, this limit was hit — resulting in the system panicking. The FL2 Rust code that makes the check and was the source of the unhandled error is shown below:

This resulted in the following panic which in turn resulted in a 5xx error.

How Cloudflare Resolved It

Once they understood the issue, the response happened in several steps:

• They stopped generating and distributing the bad feature file.
• They injected a known-good version of the file into the distribution pipeline.
• They restarted the proxy so it would load the good file.
• Workers KV and Access were temporarily shifted to fallback paths to avoid relying on the failing proxy.

By 14:30 UTC, core traffic started recovering.
By 17:06 UTC, all downstream services were stable again.

Final Thoughts

Cloudflare described this as their worst outage since 2019. A small internal permissions change led to an oversized config file, which caused a core part of their proxy to crash, a classic example of how tiny changes in distributed systems can ripple into massive failures.

Incidents like this are painful, but they lead to stronger, more resilient infrastructure for the entire Internet.

Source : https://blog.cloudflare.com/18-november-2025-outage/

Want to crack your next interview?
Get 10% OFF on Educative.io System Design courses here : https://www.educative.io/

Subscribe to my Youtube Channel : https://www.youtube.com/@scortierHQ

Follow me on LinkedIn, X and Instagram to stay updated.

See you next week with more exciting content!

Signing Off,
Scortier

Generative AI tools are impressive, but I've long argued that they aren't very useful in the real world unless they have access to more information than just their training data and can actually do something with it. It's this ability that allows AI tools to create usable content, offer useful insights, and perform actions that actually move work forward.

MCP (Model Context Protocol) changes that. It gives AI agents a simple, standardized way to plug into tools, data, and services, no hacks, no hand-coding.

With MCP, AI goes from smart… to actually useful.

What is MCP, Really ?

MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.

While it may sound technical, but the core idea is simple: give AI agents a consistent way to connect with tools, services, and data, no matter where they live or how they’re built.

MCP helps you build agents and complex workflows on top of LLMs. LLMs frequently need to integrate with data and tools, and MCP provides:

• A growing list of pre-built integrations that your LLM can directly plug into

• The flexibility to switch between LLM providers and vendors

• Best practices for securing your data within your infrastructure

Before MCP, each of those actions required a unique API, custom logic, and developer time to glue it all together.

In short: Instead of ad-hoc workarounds, MCP provides a single, real-time protocol designed for autonomous agents.

Subscribe now

How does MCP work ?

Now, let's look at more of the nitty-gritty. MCP operates using a client-host-server model:

• The MCP host—typically, a chatbot, IDE, or other AI tool is the central coordinator within the application: it manages each client instance and controls permissions and security policies. Depending on how things are set up, the host may decide to call for something over MCP based on your request or based on an automated process.

• The MCP client is initiated by the host and connects to a single server; it handles communications between the host and the server.

• The MCP server connects to a data source or tool, either local or remote, and exposes specific capabilities. For example, an MCP server connected to a file storage app can provide capabilities like "search for a file" and "read a file," while an MCP server connected to your team chat app can provide capabilities like "get my latest mentions" and "update my status." Anthropic maintains a list of available MCP servers, or if you're a developer, you can write your own.

MCP servers can provide data using three basic methods:

• Prompts are pre-defined templates for the LLM that can be selected by the user through slash commands, menu options, and the like.

• Resources are structured data, like files, data from a database, or a commit history that provide additional context to the LLM.

• Tools are functions that allow the model to take action, like interacting with an API or writing something to a file.

While MCP might sound superficially similar to how APIs operate, the two differ significantly in design, intent, and flexibility. An API offers a direct, service-specific interface, while MCP is designed to be a unified framework. Many MCP servers use APIs when they're triggered over MCP, so the two often work in tandem, but they're not the same thing.

MCP vs. AI agents

AI agents are AI-powered tools that are able to act autonomously. As a basic example, ChatGPT Deep Research is able to decide what web searches to perform and websites to visit based on your query. You tell it what you want, but it decides how it's going to give it to you.

MCP has the capacity to enable agentic behavior. By allowing developers to connect apps and data sources to AI assistants, they can build AI tools capable of making autonomous decisions and taking action in other apps. But MCP isn't the only way to build AI agents nor does using MCP automatically make any AI-powered tool an AI agent. It's simply a way of connecting an AI to another tool.

MCP is designed primarily for developers building custom integrations and AI applications, it's ideal for teams with technical resources who need to build specialized AI capabilities into their own applications or workflows.

Both approaches have their place in the ecosystem: MCP gives developers deeper control and flexibility for custom implementations, while no-code tools offer accessibility and speed for business users or teams without extensive development resources.

Marketplaces Are Here

Here are the ones to watch:

• mcpmarket.com - A plug-and-play directory of MCP servers for tools like GitHub, Figma, Notion, Databricks, and more.

• mcp.so - A growing open repo of community-built MCP servers. Discover one. Fork it. Build your own.

• Cline’s MCP Marketplace - A GitHub-powered hub for open-source MCP connectors anyone can use.

How to get started with MCP

If you're a developer building an AI app and want it to be able to initiate tasks in other apps not just access data then MCP is well worth a look. It gives your AI tools the ability to trigger actions in external systems, like sending messages, creating records, or kicking off workflows, all through a standardized protocol. And if you don't want to create your own server, you can find a list of available MCP servers here.

For more Deep Dive

Here are some great places to explore MCP further:

• Introducing the Model Context Protocol by Anthropic

• Model Context Protocol on GitHub

Hope you enjoyed this deep dive into “MCP Explained” and how it connects AI to your data and tools ? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

Follow me on LinkedIn, X and Instagram to stay updated.

I hope you have a lovely day!

See you next week with more exciting content!

Signing Off,
Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : Why Redis is Everywhere ?

Over the past few months, I went through the interview processes at several top tech companies - DoorDash, Databricks, Amazon, Uber, Stripe, Rippling, and more. I thought it would be helpful to share what the experience was like, especially for anyone preparing for similar roles.

Let’s kick things off with my Amazon SDE-2 interview experience.

💰 Quick note: The SDE-2 role at Amazon starts with a package of ₹65 LPA+, depending on location and stock grants.

Application & Online Assessment

I applied through the Amazon job portal for multiple roles. On a Sunday, I received a link to the Online Assessment (OA).

The OA included two parts:

• DSA (Data Structures & Algorithms)

• SDE Simulation

I solved all the questions and soon after, received a mail that my interviews were lined up.

Interview Process Overview

• DSA Round 1

• DSA Round 2

• System Design

• Bar Raiser

Note: There’s no separate Hiring Manager (HM) round because Amazon integrates leadership principle questions at the end of every interview.

DSA Rounds (1 Hour Each)

Each round involved 2 coding questions, ranging from medium to hard difficulty (LeetCode level). The interviews were conducted via an internal portal (similar to HackerRank), where questions were pasted and we were asked to proceed step by step.

Structure I followed:

• Clarify the problem

• Propose a brute-force solution verbally

• Optimize the solution and explain the approach

• Write code for the optimal solution (no need to run it)

• Dry run with test cases

⏱️ If you finish the first question within 30–35 minutes, they may give you a second one. I received a second question in both rounds.

At the end of each round, I was asked two leadership principle questions, which had to be answered using the STAR format.

What is STAR?

Situation – Describe the context
Task – What was the goal?
Action – What steps did you take?
Result – What was the outcome?

This format is crucial, prepare stories beforehand that map to Amazon's leadership principles.

Subscribe now

System Design Round (1 Hour)

A manager conducted this round. It began with a high-level prompt like:

“Design Twitter.”

Then it's on you to figure out everything from scratch.

My approach:

• Identify functional & non-functional requirements by discussing with the interviewer.

• Start with a basic design for ~100 users.

• Gradually scale it up to 1M users, explaining the reasoning and components along the way.

🎯 Key Insight:
Sometimes interviewers are not looking for broad coverage—they prefer deep dives into specific areas. If they steer the conversation toward one component, follow their lead. Going too broad when they expect depth may hurt your chances.

Bar Raiser Round

This is the most critical round. The outcome of the debrief is heavily influenced by the Bar Raiser.

The interviewer is usually from outside the hiring team to reduce bias. Mine was a very senior and calm individual.

We started with brief introductions, then jumped into a system design problem. I followed the same approach as in the earlier system design round, but this time the interviewer deep-dived into a specific part of the system.

They asked:

• Multiple solution approaches

• Pros & cons of each

• Which one I'd choose and why

📌 Important: There's no single “right” answer. What's evaluated is your understanding of trade-offs and your ability to communicate decisions clearly. If your logic doesn’t align with the interviewer’s and you don’t justify it well, it's game over.

The round ended with leadership questions.

Resources I Followed

• LeetCode (Mid-Hard problems)

• System Design Primer

• System Design Interview Book by Alex Xu

• Designing Data Intensive Application

• Amazon Leadership Principles

Final Thoughts

Amazon interviews are tough, structured, and fair. Be prepared to code, communicate, and tell your story. Don’t underestimate leadership questions, they matter as much as technical skills.

Hope this helps those preparing!

Loved this interview experience ? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

Follow me on LinkedIn, X and Instagram to stay updated.

I hope you have a lovely day!

See you next week with more exciting content!

Signing Off,
Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : Elasticsearch 101: Part 1

What is a CDN ?

When your app has users around the world, delivering content quickly becomes a challenge. No one likes slow load times, especially users (and interviewers in a system design round).

A Content Delivery Network (CDN) helps by storing content on servers across different locations. When someone requests a file, like an image or video, the CDN serves it from the nearest server. If it's not cached yet, the CDN fetches it from your origin server, stores it locally, and delivers it. Next time, it’s ready to go fast.

CDNs are great for static content (images, videos, HTML, CSS), and with the right setup, they can even handle some dynamic content.

A common use case? Think of a social media app like Instagram. You’d use a CDN to serve profile pictures instantly, no matter where the user is.

In short: if you care about speed, scale, and user experience, a CDN is often worth it.

Why Do We Need CDNs?

Modern websites and applications serve users across the globe, but often host content in just one or a few regions. This geographic gap causes latency, especially for users far from the origin server.

📍 Example:
Imagine your website is hosted in Mumbai. Users from Chennai, Delhi, or Kolkata would need to wait for their requests to travel all the way to Mumbai and back. Not ideal for performance or user experience.

Now, introduce a CDN: content gets cached on edge servers in nearby cities. So a user in Chennai can fetch content from a local CDN node much faster, less load on the main server.

Subscribe now

How a CDN Works

A CDN caches and serves content (like images, HTML, JS, CSS, or even API responses) from strategically located Points of Presence (PoPs). These PoPs contain edge servers that act as mini versions of your origin infrastructure.

When a user requests content:

1. The CDN checks if the content is cached on a nearby edge server.

2. If yes, it serves it directly fast.

3. If not, it fetches the content from the origin, stores it at the edge, and serves it.

4. Next time, it's already there, ready to go.

Routing Requests to the Right Server

To direct user traffic efficiently, CDNs use different routing techniques:

• DNS-based routing: Each PoP has a unique IP address. DNS returns the IP of the closest PoP.

• Anycast: All PoPs share the same IP. The network automatically routes requests to the nearest server based on location and availability.

Common CDN Use Cases (Especially in Interviews)

In system design interviews, CDNs often come up when discussing how to serve static media—like images or videos efficiently. A classic example is a social media app (like Instagram) using a CDN to cache and deliver user profile pictures quickly, no matter where the user is.

1. Not Just for Static Files
While CDNs are typically used for static assets—images, videos, JavaScript, etc.—they can also handle dynamic content that doesn’t change often. For instance, a blog post updated once a day can be cached to improve load times without serving stale content.

2. Caching API Responses
If your API endpoints return the same data to many users (e.g., trending posts or product listings), you can cache those responses using a CDN. This reduces backend load and speeds up response times.

3. Cache Eviction & Invalidation
Like any cache, CDNs don’t hold onto data forever. You can control how long content stays cached using TTL (Time To Live), or explicitly invalidate the cache when the underlying data changes. This helps keep content fresh without sacrificing performance.

Modern CDN Capabilities

CDNs have evolved far beyond just caching static files. Here's what they can do today:

• Dynamic Content Caching: Content that doesn't change frequently (like blog posts or product pages) can still be cached.

• API Caching: Repeated API responses can be cached to reduce backend load and improve response times.

• Edge Optimizations: CDNs can minify JavaScript or convert images (e.g., to WebP or AVIF) on the fly.

• TLS Termination at the Edge: CDNs handle secure HTTPS connections at the nearest edge server. This reduces the time it takes to establish a secure connection (especially with TLS 1.2 or 1.3).

• DDoS Protection: With globally distributed infrastructure, CDNs can absorb and deflect massive traffic spikes caused by denial-of-service attacks.

• Improved Availability: If one PoP goes down, others can continue to serve traffic, keeping your site up and running.

By now, you should have a clear understanding of what a CDN is, why it exists, and how it helps developers build better, faster, and more secure applications.

To sum it up:

A CDN is a geographically distributed network of servers that cache and deliver content from the location nearest to the user—making websites load faster, reducing latency, improving security, and keeping things running smoothly at scale.

In a world where user experience and performance are non-negotiable, CDNs are no longer optional, they’re essential.

Loved this deep dive? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

Follow me on LinkedIn, X and Instagram to stay updated.

I hope you have a lovely day!

See you next week with more exciting content!

Signing Off,
Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : Elasticsearch 101: Part 1

Have you ever noticed how some websites update instantly like chat apps, stock tickers, or multiplayer games without needing to refresh the page? That magical real-time experience is powered by something called WebSockets. Let’s dive in and see how they work and why they matter!

Imagine you're playing an online game, and the leaderboard keeps changing on the server. How does your browser know when to update?

One way is to ask users to refresh the page every few seconds. Or maybe have your browser keep sending requests every minute to check if something’s changed. That’s called polling and yeah, it works, but it’s not really the best way.

Every time the client sends a request, it waits for the server to respond. If there’s no new data, the server still sends back something usually an empty response. It’s like constantly asking, “Anything new?” and hearing, “Nope” over and over again.

Subscribe now

What’s the issue?

Polling creates a lot of traffic. Imagine thousands of users asking the server for updates every second — even when there’s nothing new to show. It wastes resources and can slow things down.

To make it a little better, there’s something called long polling. Here, the server doesn’t respond immediately. Instead, it waits until there’s something new to send back. If there’s still no update after a while, it times out and the client tries again.

It’s better than regular polling, but it still needs to open and close connections over and over. This takes up memory and network resources.

Enter WebSockets

WebSockets were designed to solve the limitations of polling and long polling. Instead of repeatedly opening and closing connections, WebSockets allow the client and server to establish a single, persistent connection that stays open. This enables real-time, two-way communication.

To begin, the client starts by sending a regular HTTP request to the server. But this request includes an "Upgrade" header that tells the server:
“I’d like to switch this to a WebSocket connection.”

If the server supports WebSockets, it responds with a confirmation. The HTTP connection is then upgraded to a WebSocket, and from that point on, both the client and server can freely send and receive data through this single TCP connection — without needing to reconnect each time.

Typically, a WebSocket Handler is used in the setup. It's a lightweight server-side component that maintains these open connections and manages active users. This handler ensures that real-time communication is possible across multiple users without needing to repeatedly create new connections.

To summarize the process:

• The client sends an HTTP request with an upgrade header.

• The server acknowledges and upgrades the connection to WebSocket.

• Once established, this connection remains open for ongoing two-way data exchange.

• Either the client or server can close the connection at any time, ending the communication.

This persistent connection model is what makes WebSockets highly efficient for real-time applications like chat systems, live notifications, online gaming, and more.tion at any time and the server won’t be able to send you anything now.

Why WebSockets Matter

With traditional methods like polling, the connection would close after every response, forcing the client to keep asking the server for updates. This wasn’t very efficient, especially when there was no new data to send — it just created unnecessary load.

With WebSockets, the communication channel remains open. Once the connection is established, both the client and the server can send data whenever they need to, without waiting for a request from the other side. This makes the whole process much faster and more efficient.

For example, in a real-time chat application:

• When User A sends a message, it goes to the server.

• Instead of User B constantly checking the server for new messages, the server can immediately send the message to User B over the open WebSocket connection.

• There’s no delay, no need to reconnect, and no extra overhead — just instant communication.

This model not only reduces server load but also improves the user experience by delivering updates in real time.

If at any point the client or server no longer needs the connection for example, if the user leaves the chat either side can close it. Once closed, no further messages can be sent through that connection.

Why Not Just Use HTTP?

Here's how standard HTTP works:

• Client says: "Hey server, got anything for me?"

• Server replies: "Here you go!" (or "Nope, nothing right now.")

• Then... they hang up.

It’s always request → response → disconnect.

If you want more data, you have to ask again. And again. And again. Not great for real-time updates.

What makes WebSockets special?

• Real-time updates: Messages, prices, scores — all get pushed instantly.

• Less overhead: One open connection, not thousands of repeated ones.

• Two-way communication: Both sides can send data anytime.

It works over a TCP connection and keeps everything fast and responsive.

Where are WebSockets used?

WebSockets are everywhere in modern apps that need to be real-time.

• Chat apps like WhatsApp or Messenger use them to send and receive messages quickly.

• Stock apps use WebSockets to show live price updates.

• Online games rely on it for smooth, instant interactions.

It’s not just for browsers either lots of backend systems use WebSocket-based tools to power things behind the scenes.

When NOT to use WebSockets?

WebSockets are great, but they’re not always the right tool. If you're just loading data once — like fetching a list of users or getting a product page, a regular HTTP request is easier and lighter. It shine when you need updates right away and all the time.

So that’s WebSockets in a nutshell. They let your browser and server keep an open line of communication, sending messages back and forth in real-time. No more asking, no more waiting.

They’re perfect for anything where speed and instant updates matter chats, games, live scores, stock updates, and more.

It’s one of those things that makes the web feel alive. And now you know how it works!

I hope, by now you must have had a clear idea of WebSockets, from its meaning to working you know all of it now.

Loved this deep dive? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

Follow me on LinkedIn, X and Instagram to stay updated.

I hope you have a lovely day!

See you next week with more exciting content!

- Scortier

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : Elasticsearch 101: Part 1

Don’t forget to check out the latest job openings at the end of the article!

In Part 1, we explored the basics of Elasticsearch, what it is, how you use it, and how it fits into modern systems. Now, let’s take a peek under the hood.

Okay, so you know how searching through tons of stuff online is usually pretty quick? Elasticsearch is a big reason for that. Now, Elasticsearch is cool on its own, but it's built on top of something even cooler: Apache Lucene.

Think of Lucene as the real engine for searching – it's super-fast at the nitty-gritty stuff. Elasticsearch is like the person managing that engine, making sure it runs smoothly when you have lots of different parts working together. It handles all the behind-the-scenes stuff like keeping your search setup organized (that's the "cluster"), giving you easy ways to talk to it, doing calculations across all your data, and making sure you get results right away. Lucene does the actual searching, but Elasticsearch makes it work for big, complex setups.

There's a lot to talk about, but let's start with how an Elasticsearch setup (a "cluster") is organized. Then we can look at how it gets your information ready to be searched and how it actually finds what you're looking for.

Subscribe now

The Different Helpers: Node Types

Elasticsearch likes to work as a team, so you usually have a bunch of servers running together – we call these "nodes." When you start Elasticsearch, you're basically starting up a few of these helpers. Each helper can have a specific job. Here are the main roles:

• Master Node: This is like the team leader. It's in charge of the whole operation – adding or removing helpers, and creating or getting rid of your search collections (we call them "indices").

• Data Node: These are the ones who actually hold all your information. If you have a lot of stuff to search, you'll have a lot of these helpers.

• Coordinating Node: This is the friendly face that takes your search requests and then talks to the other helpers to get you the answers. It's like the person you first talk to.

• Ingest Node: This is the one who gets your information ready. It takes your raw data and prepares it so the Data nodes can store and search it easily.

• Machine Learning Node: This helper does any of the fancy computer learning stuff you might want to do with your data.

All the different "helpers" in Elasticsearch - like the ones that prep data (Ingest), store it (Data), or handle queries (Coordinating) - work together like a well-organized team. Imagine the Ingest helpers cleaning up raw data and handing it off to the Data helpers, who carefully store it away.

The cool part? One server can wear multiple hats! A single server might act as the team leader, a friendly receptionist, and a storage unit all at once. But in larger setups, it's common to split the roles across multiple machines. For example, data prep might need a lot of CPU power, while storing tons of data requires disk space.

It gets even more organized—data can be split based on how often it’s needed:

• Hot data: used all the time, super fast access.

• Warm data: accessed occasionally.

• Cold data: rarely touched.

• Frozen data: almost never used, but still there just in case.

This structure helps Elasticsearch balance performance and cost really well.

Data Nodes: Where the Searching Happens

The Data helpers in Elasticsearch are the ones doing the heavy lifting - they safely store your documents and make them lightning-fast to search. How? By keeping two things:

1. The original data (your full documents)

2. The Lucene-powered indexes (think: smart shortcuts for searching)

Imagine you’re in a library. The actual books are your documents, and the index at the back of each book helps you jump right to the good stuff. That’s how search works in Elasticsearch.

When you run a search, two steps kick in:

• Query phase: Elasticsearch uses those Lucene indexes to quickly find which documents match your search.

• Fetch phase: Then it pulls the actual document content from the Data helpers so you can read it.

Now, inside these Data helpers live your indices - basically organized folders of documents. These indices are split into shards (smaller chunks), and each shard can have one or more replicas (backups). And each shard has its very own Lucene index inside, like mini search engines inside your main search engine.

"Sharding" is what lets Elasticsearch spread your information (and those search shortcuts) across multiple servers. This is what makes it really fast and able to handle tons of data. When you search, Elasticsearch can ask all the relevant parts at the same time, and then the friendly face helper puts all the answers together for you.

Now, about those "replicas." They're just exact copies of your shards. Why have copies? Two main reasons:

1. Keeping Things Running: If one of your servers has a problem, the copy can jump in and make sure you can still access your information. It's like having a spare tire.

2. Handling More Searches: If one part can handle, say, 10 searches at once, then having a copy means you can probably handle 20 at once (roughly speaking). It's like having more checkout lanes at a store.

Lastly, remember that each of those Elasticsearch parts (shards) has its own little Lucene search engine inside. So, a lot of what Elasticsearch does with these parts – like putting smaller pieces together, making them fresh, and of course, searching – is really just telling the Lucene engines inside what to do.

Lucene's Building Blocks: Segments

Think of a Lucene index as being made up of smaller chunks called "segments." These segments are the basic units our search engine works with. Now, here's a key thing to wrap your head around: once a segment is created, it can't be changed. Let that sink in for a sec. You might be thinking, "Wait a minute, don't we constantly add, update, and delete stuff in our Elasticsearch data?" Good question!

The way Lucene handles this is by being clever with how it writes. When you add a new document, it doesn't go straight into an existing segment. Instead, it gets bundled up with other new documents. Once there's a little batch of them, Lucene creates a brand new segment and writes all those documents into it. It's like collecting your dirty laundry and then doing a whole load at once, rather than washing each sock individually.

Now, what happens when you have a ton of these segments? It can get a bit messy. So, Lucene has a process to merge them. It takes a few segments, combines them into a new, bigger segment, and then gets rid of the old smaller ones. It's like taking a bunch of small piles of papers and combining them into a few larger, more organized stacks.

When you delete a document, Lucene doesn’t erase it right away. Instead, it marks it as "invisible"—like sticking a Post-it note that says "ignore this one." The actual data is still there until Lucene later cleans it up during segment merges.

Updating is even trickier! There’s no in-place update. Instead, Lucene marks the old version as deleted and adds the new version as a brand-new document. So technically, every update is a delete + insert behind the scenes.

This makes both deletes and updates really fast—at first. But over time, too many of them can slow things down until Lucene merges and tidies things up. So go easy on those frequent updates!

This "can't change once it's written" approach (we call it immutability) actually has some pretty cool benefits for Lucene:

• Faster Writing: Adding new stuff is quick because it just goes into new segments without messing with the old ones.

• Efficient Caching: Since segments never change, the system can safely keep copies of them in memory (like a super-fast shortcut) without worrying that the data will become outdated.

• Simpler Coordination: When you're searching, the system doesn't have to worry about the data changing while it's in the middle of looking. This makes things much simpler when lots of people are searching at the same time.

• Easier Recovery: If something crashes, it's easier to get back up and running because the segments are in a consistent, known state.

• Better Compression: Data that doesn't change can be squeezed down more effectively to save disk space.

• Quicker Searches: The unchanging nature of segments allows for some really clever and fast ways to organize and search the data.

What's Inside These Segments?

Segments aren't just dumb containers holding your documents. They also have some super smart data structures inside that make searching really fast. Two of the most important ones are the inverted index and doc values.

The Inverted Index: The Heart of Fast Search

If Lucene is the heart of Elasticsearch, then the inverted index is definitely the heart of Lucene. Basically, if you want to find things quickly, you have a couple of main strategies:

1. Organize your data based on how you want to find it. For example, if you want to quickly look up a specific book by its ID, a simple list where you have to check every book (O(n) – that's computer science speak for "slow for lots of books") would be bad. A sorted list (O(log(n)) – better) would be okay, but a hash table (O(1) – super fast!) would be ideal.

2. Make a copy of your data and organize that copy in a smart way (like in point 1).

Let's say you have a billion books, and only a few of them have the word "great" in the title. How would you find those books as fast as possible?

An inverted index is like a special kind of index that maps words (or numbers, etc.) to where they appear in your data (in our case, which documents they're in). This is what makes keyword search with Elasticsearch so speedy. It lists every unique word that appears in any of your documents and then tells you exactly which documents contain that word. So, for our "great" example, the inverted index would have an entry like:

"great" -> [document #12, document #53, ...]

Now, instead of having to look through every single book to see if the title contains "great," we can just look up "great" in our inverted index and BAM! We instantly know which documents have it.

Doc Values: For Sorting and More

When you want to sort search results, say by price - Elasticsearch uses something called doc values to keep things fast.

Instead of scanning every full document just to get one field (like traditional row-based databases), Elasticsearch stores field values like "price" in a columnar format. This means all the prices are stored together, all the authors together, and so on.

So when you search for books with "great" in the title and want to sort them by price, Elasticsearch can quickly grab just the price values from memory, sort them, and return the results—without touching the rest of the document. Efficient and speedy!

Coordinating Nodes: The Traffic Cops

Remember how Elasticsearch is like a team of servers? Well, coordinating nodes are the traffic cops of that team. When you send a search request, they’re the first to receive it. Their job is to figure out which servers (nodes) need to help answer the query, send out those requests, and then gather all the results and stitch them together for you.

One of their biggest responsibilities is query planning—basically, choosing the smartest, fastest way to get your answer. Think of it like them plotting the most efficient route on a GPS before you hit the road. After the coordinating node understands what you're asking for, the query planner figures out things like:

• Should we use the inverted index?

• If our search has multiple parts, what's the best order to do them in?

• How should we combine the results we get back from all the different servers?

Order Optimization: Being Smart About Searching

Let's say you're searching for the phrase "bill nye" across millions of documents. In our inverted index, the word "bill" might appear in millions of documents, but the word "nye" might only appear in a few hundred. How should the system go about finding documents that contain both? There are a bunch of ways it could do it:

• Find all documents with "nye," then check each of those to see if they also contain "bill" and then do a more detailed check for "bill nye."

• Find all documents with "bill," then check each of those for "nye" and then do a more detailed check for "bill nye."

• ...and many other possibilities!

The difference in speed between these approaches can be huge!

By keeping track of information about the data (like which words are common, how long documents are, etc.), Elasticsearch's query planner can make smart choices about the best way to perform the search. It tries to minimize the amount of work needed to get you your results quickly. This optimization becomes really important as your data gets bigger and your searches get more complex.

I hope you’ve got a good grasp of how Elasticsearch works under the hood, its inner workings, exploring the cluster architecture, and much more.

Loved this deep dive? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

Follow me on LinkedIn, X and Instagram to stay updated.

I hope you have a lovely day!

See you next week with more exciting content!

Signing Off,
Scortier

Exciting Job Opportunities 🚀

• Software Engineer, Rippling : Link

• Software Engineer, Atlassian: Link

• Software Engineer, Backend, Coinbase : Link

• Software Engineer, Amazon : Link

• Software Engineer, Google : Link

• Software Engineer, Uber : Link

• Software Engineer, Meta : Link

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : CAP Theorem Explained!

Don’t forget to check out the latest job openings at the end of the article!

Intro

A lot of system design problems boil down to one thing: finding stuff. You’ve got a huge pile of "things" and need a smart way to get the right one when you ask for it. Sure, databases like Postgres (with full-text search) can handle that up to a point. But when things get serious, think more scale, more features, you’ll want a tool built just for the job. That’s where Elasticsearch shines.

Elasticsearch is one of the most popular search engines out there. It's fast, it’s flexible, and it’s built to handle stuff like sorting, filtering, ranking, and all the other bells and whistles that make modern search actually useful.

Basics

Let’s start with the basics. If you're working with Elasticsearch, there are a few key terms you’ll hear all the time: documents, indices, mappings, and fields.

Documents

Think of documents as the core pieces of data you’re storing and searching. Don’t let the term throw you off, it doesn’t have to be a blog post or a PDF. In Elasticsearch, a document is just a JSON object.

Here’s a new example: imagine you’re building a recipe app. Each recipe can be a document, like this:

{
  "id": "RECIPE001",
  "title": "Spaghetti Carbonara",
  "chef": "Mario Rossi",
  "ingredients": ["spaghetti", "eggs", "pancetta", "parmesan", "pepper"],
  "prepTimeMinutes": 25,
  "createdAt": "2025-03-12T10:00:00.000Z"
}

This is what Elasticsearch will index and allow you to search through, by title, chef, ingredients, or whatever else you include.

Subscribe now

Indices

An index in Elasticsearch is basically a collection of documents. Think of it like a table in a traditional database, each document in that index has a unique ID and a bunch of fields (just key-value pairs) that hold the data you want to search.

For example, in our recipe app, we might have an index called recipes, where each document is a different recipe.

Just a quick note: the word index can be a bit confusing. In general tech terms, “index” often means a data structure that makes lookups faster (like in SQL). Here in Elasticsearch, we’re talking about the top-level container that holds documents.

You could have multiple indices, one for recipes, one for chefs, another for user reviews, and so on, whatever makes sense for your app. And when you search, you’re querying one or more of these indices to find what you need.

Mappings and Fields

Okay, so you’ve got your documents, and you’ve got your index. But how does Elasticsearch know what kind of data it’s dealing with? That’s where mappings come in.

A mapping is like a blueprint or schema for your index. It tells Elasticsearch, “Hey, this field is a number, that one’s a date, and this one over here? Yeah, treat it like plain ol’ text.”

For example, let’s say we’re storing recipes. Here’s a simple mapping:

{
  "properties": {
    "id":        { "type": "keyword" },
    "title":     { "type": "text" },
    "chef":      { "type": "text" },
    "rating":    { "type": "float" },
    "createdAt": { "type": "date" }
  }
}

Let’s break that down:

• id is a keyword, which means it’s not broken up, Elasticsearch treats it as a single value, perfect for exact matches.

• title and chef are text, so they get analyzed and split up into terms. Useful for full-text search (like searching for "chocolate").

• rating is a float, so we can sort or filter by it.

• createdAt is a date, which means we can do date-range queries and sorting.

Elasticsearch is super flexible, you can even use nested objects, arrays, geolocation fields, or fancy stuff like embeddings for AI-powered search. But don’t worry, you don’t need all of that to get started.

Tip:

Only include fields you actually need for searching or filtering. Adding extra fields “just in case” makes your index bigger and slower. If you’re only searching on 2 out of 10 fields, don’t waste memory on the other 8!

Mapping is one of the best tools you have to control search behavior and performance, so get to know it well!

Let’s walk through a series of operations to create an index, store some data, and perform a search to get a feel for the essential functionality.

Elasticsearch offers a clean and friendly REST API to handle these operations. You can use tools like curl, Postman, or Kibana’s Dev Tools interface to interact with your cluster. While Elasticsearch also has many client libraries and GUI tools, the REST API is where everything starts.

This step-by-step flow gives you a taste of what working with Elasticsearch actually looks like.

Use Cases

Creating an Index

Imagine you're starting a library and need to set up shelves. A basic index is like setting up your shelves in a library. By default, Elasticsearch will automatically organize things for you, but you can add your own specific instructions, like how many shelves (shards) you want and how many backup shelves (replicas) there should be. Here's a quick example:

PUT /library
{
  "settings": {
    "number_of_shards": 2,
    "number_of_replicas": 1
  }
}

Setting a Mapping

Now, you want to tell Elasticsearch exactly how to handle each book (field). Maybe you have a "title," an "author," and a "price" that need to be treated differently, right? Let’s be clear about the categories (types) before we start putting in books. Here's what that could look like:

PUT /library/_mapping
{
  "properties": {
    "title": { "type": "text" },
    "author": { "type": "keyword" },
    "price": { "type": "float" },
    "publish_date": { "type": "date" }
  }
}

Now Elasticsearch knows that your books will have titles, authors, prices, and publish dates. You can add more complex stuff, like reviews, later if needed.

Adding Documents

Now, let’s fill up our shelves! To add books, you just make a quick POST request. For instance, let's add a book:

POST /library/_doc
{
  "title": "The Alchemist",
  "author": "Paulo Coelho",
  "price": 15.99,
  "publish_date": "1988-05-01"
}

When Elasticsearch accepts this, it’ll give you a nice little ID for the book (like a library catalog number). So, you can always retrieve or update it later.

Updating Documents

Let's say you want to raise the price of "The Alchemist" because it's now a bestseller. You can do that with a PUT request. Just target the book by its unique catalog ID:

PUT /library/_doc/1
{
  "title": "The Alchemist",
  "author": "Paulo Coelho",
  "price": 19.99,
  "publish_date": "1988-05-01"
}

But beware! If someone else is also updating the same book at the same time, you could accidentally overwrite their changes. Elasticsearch offers a little helper called the version number to avoid that.

Search

Now that we have books in the library, let’s search for them! If you’re looking for books by Paulo Coelho, just use a simple search like this:

GET /library/_search
{
  "query": {
    "match": {
      "author": "Paulo Coelho"
    }
  }
}

Boom! You’ll get all the books by this author. What if you want to look for books that cost less than $20? No problem!

GET /library/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "author": "Paulo Coelho" } },
        { "range": { "price": { "lte": 20 } } }
      ]
    }
  }
}

Now you're getting books that are by Paulo Coelho and cost under $20.

Sort

But wait, we’re not done! Sometimes you want to see the books in a certain order. Maybe you want to see the cheapest books first or the newest ones last. Sorting is simple:

Sort by price (ascending):

GET /library/_search
{
  "sort": [
    { "price": "asc" }
  ],
  "query": {
    "match_all": {}
  }
}

Sort by price and then by publish date (descending):

GET /library/_search
{
  "sort": [
    { "price": "asc" },
    { "publish_date": "desc" }
  ],
  "query": {
    "match_all": {}
  }
}

This sorts first by price, and then if two books have the same price, it sorts them by publish date, starting from the most recent.

Nested Searches

Let’s add a little complexity! Imagine you have a list of reviews for each book. You can search through these reviews to find books with the best ratings. Check this out:

GET /library/_search
{
  "query": {
    "nested": {
      "path": "reviews",
      "query": {
        "bool": {
          "must": [
            { "match": { "reviews.comment": "life-changing" } },
            { "range": { "reviews.rating": { "gte": 4 } } }
          ]
        }
      }
    }
  }
}

This searches for books with a review comment containing "life-changing" and a rating of 4 or more stars. Talk about precision!

How Elasticsearch Works ?

So, you’re already using Elasticsearch, but ever wonder what’s going on behind the scenes? How is it making everything so fast and smooth? Here’s the scoop:

At the core, Elasticsearch is powered by Lucene, a super-efficient search library. Think of Lucene as the engine that does all the heavy lifting, and Elasticsearch is the conductor making sure everything runs in sync.

What’s Happening in Elasticsearch?

1. Cluster: This is like a team of servers working together. It’s like a library, but bigger—think multiple libraries in different cities working as one.

2. Node: Each server in the cluster is a node. So, every node is like a librarian with their own little section of the library.

3. Index: This is where your data (like documents or books) is stored. It’s the bookshelf where Elasticsearch keeps everything organized.

4. Shards and Replicas: To make sure everything is fast and safe, Elasticsearch breaks up each index into shards, tiny chunks of data. These chunks are spread across different servers (nodes). And just like having backup copies of your favorite book, replicas are extra copies of these chunks to keep your data safe and available.

Indexing: How Elasticsearch Organizes Your Stuff

When you add data to Elasticsearch, it doesn’t just throw it into a random pile. It indexes it, which means it organizes everything neatly to make searching super quick. This is done with something called an inverted index.

Here’s an easy way to think about it: imagine a book index. You look up a word, and it tells you all the pages where that word appears. Elasticsearch does this for every single word in your data. So when you search for something, it doesn’t have to read everything, it just checks the inverted index to find exactly what you need, super fast.

Searching: How Elasticsearch Finds What You Want

When you search, Elasticsearch doesn’t go through every document one by one. Here’s how it works:

1. Your Search: You type something like, “Find books by Paulo Coelho,” and Elasticsearch figures out where that data is stored.

2. Distributed Search: Since Elasticsearch is spread out over multiple servers (nodes), it sends the search request to all the right places.

3. Lucene Does the Work: Each server uses Lucene to find the documents that match your search.

4. Results: Elasticsearch collects the results from all the servers and sends them back to you.

Wrapping Up!

I hope you’ve got a good grasp of how Elasticsearch works so far! In the next part, we'll dive even deeper into its inner workings, exploring the cluster architecture, and much more.

Loved this deep dive? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

See you next week with more exciting content!

Exciting Job Opportunities 🚀

• Software Engineer, Core Infra, Stripe : Link

• Software Engineer, DE Shaw : Link

• Software Engineer, Backend, Coinbase : Link

• Software Engineer, Google : Link

• Software Engineer, Uber : Link

• Software Engineer, Meta : Link

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : CAP Theorem Explained!

Don’t forget to check out the latest job openings at the end of the article!

What is Redis ?

Ever wondered how apps like Amazon or Twitter retrieve data so fast? ⚡

Every time you scroll, search, or shop there’s a behind-the-scenes hero making sure things run blazingly fast.

That hero? Redis.

Redis is a “data structure store” but not your typical one. It’s written in C, runs in-memory and is single-threaded 😱 and that’s exactly what makes it blazingly fast.

Redis Cache is like a super-speedy assistant that stores data in memory (RAM), so your apps don’t have to wait around querying a slower database.

It’s open-source, easy to work with, and runs quietly in the background but the impact it makes is massive.

The story behind Redis: Back in 2009, when platforms like Twitter were scaling like crazy, traditional databases just couldn’t keep up. Redis was built to solve this based on the bold idea that a cache can be more than just a temporary store. It can be fast and reliable.

NOTE:

Redis is fast but speed comes with trade-offs. ⚠️

One thing to keep in mind: Redis isn’t built for durability out of the box.

Since it’s an in-memory store, if the server crashes, your data could vanish. Redis does offer ways to reduce this risk like the Append-Only File (AOF) but it's not the same level of durability you’d get from traditional databases that write every commit to disk.

This isn’t a bug it’s a design choice by the Redis team to prioritize blazing speed over guaranteed persistence.

But, if you do need stronger durability, options like AWS MemoryDB exist. They’re based on Redis but trade a bit of speed for more safety.

📌 So, ask yourself: Do I need ultra-low latency, or do I need data to survive a reboot?
Your answer will guide the tool you pick.

Subscribe now

Data Structure Support

Redis isn't just a cache it's a powerful playground of data structures. At its core, It is a key-value store but what you store in those keys can be surprisingly diverse.

Here are some of the fundamental data structures Redis supports:

• Strings – The simplest type, great for basic caching.

• Hashes – Think of them like lightweight JSON objects.

• Lists – For pushing/popping elements, like a queue or stack.

• Sets – Unique unordered elements.

• Sorted Sets – Ordered with scores — great for things like leaderboards or priority queues.

• Bloom Filters – For fast probabilistic checks (e.g., has this been seen before?).

• Geospatial Indexes – Perfect for location-based queries.

• Time Series – Ideal for logging or tracking values over time.

And Redis goes beyond just storing data. It also supports communication patterns like:

• Pub/Sub — For real-time messaging.

• Streams — For ordered message processing, somewhat like Kafka-lite.

Whether you're building a real-time leaderboard, a geolocation app, or a chat system, Redis has something built-in to help you out all while staying fast and easy to reason about.

Commands

One of the best things about Redis? You don’t need to learn a complex query language to use it. Redis uses a simple, custom string-based protocol that feels super natural — especially if you’ve used data structures in any programming language.

You can literally connect to a Redis instance and run commands like these straight from the CLI:

SET foo 1 # Store key 'foo' with value 1 
GET foo # Returns 1 
INCR foo # Increments 'foo', returns 2 
XADD mystream * name Sara surname O
Connor # Adds an entry to a stream

And the best part? Commands are grouped by data structure and they make sense.

For example, Redis Sets come with:

• SADD – Add an element

• SCARD – Get total number of elements

• SMEMBERS – List all elements

• SISMEMBER – Check if an element exists

It’s like working with a Set in your favorite language just faster and persistent across networked systems.

Performance

Redis is fast like really fast. It can handle over 100k writes per second, and read latency is usually in the microsecond range.

Because of this, you can get away with patterns that would usually be a bad idea in traditional databases. For example, running 100 separate SQL queries to build a list is something you'd avoid with a relational DB. But with Redis, that kind of overhead is much lower. It’s still better to keep things efficient, but if you do need to make a lot of small calls, Redis can handle it.

This is mainly because Redis keeps everything in memory. That makes it great for performance-heavy use cases. It’s not the right fit for everything, especially if you need strong durability, but in the right scenarios, it works really well.

Infrastructure Configuration

Redis can be deployed in different ways depending on your needs as a single node, with a high availability replica, or as a cluster.

When using Redis in cluster mode, each client caches a set of hash slots. These slots map keys to specific nodes, so the client knows exactly which node to contact for a given key. This direct mapping helps Redis maintain its performance edge.

Redis nodes also talk to each other using a gossip protocol. So if a client ends up asking the wrong node for a key, it can be redirected but ideally, you want to hit the correct node on the first try.

Compared to most distributed databases, Redis clustering is quite minimal. It doesn’t abstract away scalability problems instead, it gives you just enough tools to build your own solutions.

For example, Redis assumes that all the data needed for a request lives on one node. So if your data is spread out or your keys are poorly designed, things can fall apart.

That’s why key structure and partitioning strategy play a huge role in scaling Redis effectively. It’s less about what Redis gives you out of the box, and more about how you build on top of it.

Capabilities

Redis as a Cache

One of the most common ways Redis is used is as a cache. In this case, the keys and values in Redis directly represent the keys and values we want to store in the cache.

Redis makes it easy to scale, it can distribute this key-value map across multiple nodes in a cluster. So if you need more capacity, you just add more nodes.

When caching with Redis, it's common to set a TTL (time to live) on each key. Once the TTL expires, Redis ensures that the key is no longer accessible. It also uses TTLs to decide which keys to evict, which helps keep memory usage under control — especially when you're trying to cache more data than your memory can hold.

That said, using Redis as a cache doesn’t solve everything. One common issue is the “hot key” problem where one key gets a lot more traffic than others. This isn’t unique to Redis though; tools like Memcached and even large-scale databases like DynamoDB face similar challenges.

Official Doc: Redis as a Cache

Redis as a Distributed Lock

Sometimes, you’ll need to ensure consistency when multiple users are interacting with your system. For example, when designing a system like Ticketmaster, you need to make sure the same ticket isn’t sold twice. Or in something like Uber, you have to make sure two drivers aren’t assigned the same ride.

Most databases including Redis provide some level of consistency. If your main database already handles it well, it’s usually better to rely on that instead of introducing a distributed lock. Distributed locks can add complexity, and interviewers often dig into edge cases when you use them.

That said, Redis does support basic locking mechanisms. A simple distributed lock might use the INCR command with a TTL. You try to acquire the lock by calling INCR. If the result is 1, you own the lock and can proceed. If it’s more than 1, it means someone else already has it so you wait and try again later. Once you're done, you DEL the key to release the lock.

For more advanced use cases, Redis also supports the Redlock algorithm a more robust way to handle distributed locking across multiple nodes.

Read more : Redis Official Doc for Distributed Lock

Redis for Ranking

Redis' sorted sets are great for keeping data in order which makes them a perfect fit for leaderboard-style use cases. Since inserts and reads are fast, even at scale, they can handle scenarios where a traditional SQL database might struggle.

Let’s say we’re building a feature where users search for cricket-related topics, and we want to show the most liked posts for that keyword.

For example, when someone searches for "kohli", we can maintain a sorted set of posts containing that keyword, ranked by the number of likes.

ZADD kohli_posts 320 "PostId123" # A post about Kohli's century 

ZADD kohli_posts 75 "PostId456" # A post about Kohli's training session 

ZREMRANGEBYRANK kohli_posts 0 -6 # Keep only the top 5 posts

This gives us a quick way to fetch the most engaging content related to a specific keyword, and we can periodically clean up the lower-ranked posts to keep things efficient.

Redis for Sliding Window Rate Limiting

Instead of traditional fixed window rate limiting, Redis can implement sliding window rate limiting using sorted sets. Each request adds a timestamp to the sorted set, and the system checks how many requests exist in the last N seconds. For example, if an API allows 100 requests per 60 seconds, Redis can dynamically reject requests once that threshold is crossed. This approach ensures smooth limiting, avoids sudden spikes, and is much fairer to end users.

Redis for Proximity Search

Redis also supports geospatial indexes out of the box using commands like GEOADD and GEORADIUS. These are useful when you need to store locations and perform quick proximity searches.

Here’s how it works:

GEOADD nearby_restaurants 77.5946 12.9716 "PizzaPlace" # Add a restaurant at a specific location 

GEORADIUS nearby_restaurants 77.5946 12.9716 5 km # Find restaurants within 5 km

In this example, we’re storing the location of restaurants and then searching for places near a user’s location. This is useful for features like showing nearby food outlets in a food delivery app.

The GEORADIUS command runs in O(N + log(M)) time, where N is the number of elements within the radius and M is the total number of elements in the index.

Redis for Event Sourcing

Redis streams are append-only logs, somewhat like Kafka topics. They let you add data in a durable way and provide a built-in mechanism for distributing that data to multiple consumers.

Redis supports this with two key features:

• XADD to push new items to the stream

• Consumer groups (XREADGROUP, XCLAIM) to read and manage those items

Let’s take a work queue as an example. Imagine you're queuing up background jobs like sending emails. You push each job into the stream using XADD. Now, you have a group of workers (in a consumer group) processing these jobs. Redis tracks what each worker has acknowledged and what’s still pending. If a worker crashes midway, Redis doesn’t lose track. Another worker can use XCLAIM to pick up the unacknowledged message and reprocess it.

This setup gives you reliability and fault tolerance without needing a separate queuing system.

Redis for Write Coalescing (Debouncing)

In high-frequency write scenarios, it’s inefficient to hit your database on every update. Redis can act as a buffer to hold temporary state and update the primary database periodically. For example, in a collaborative document editor, where users type rapidly, every keystroke doesn’t need to be stored in the DB. Instead, Redis can store the intermediate state and sync it every few seconds. This reduces backend load and improves responsiveness, without losing any data.

Hot Key Issue

One common problem you might run into when using Redis at scale is the "hot key" issue. This happens when traffic is heavily focused on just one or a few keys, causing uneven load across your Redis cluster.

Let’s say you're building a social media platform and using Redis to cache user profile data. You’ve distributed user keys evenly across a 50-node Redis cluster. Everything’s running smoothly.

Now imagine a celebrity joins the platform and millions of users start viewing their profile at the same time. Suddenly, the Redis node storing that celebrity’s profile data is handling way more traffic than any other node.

Unless your cluster is overprovisioned with lots of spare capacity, that node will likely become a bottleneck and start failing even though the rest of the cluster is underutilized.

Here are a few ways to handle this:

• Client-side caching: Cache the celebrity’s profile data on the frontend or at the edge so you don’t hit Redis every time.

• Key duplication: Store the same profile under multiple keys and randomly pick one for reads, distributing load across multiple nodes.

• Read replicas: Add replicas for the hotspot node and load-balance requests across them dynamically.

For system design interviews, what matters most is that you identify the hot key problem early and proactively suggest mitigation strategies. It shows you’re thinking beyond the happy path.

Wrapping Up!

By now, you should have a clear understanding of Redis, what it is, how it works, where it fits in, and why it’s used.

Its speed and flexibility make it a top choice for many large-scale systems. From caching and real-time analytics to queues and pub/sub. Redis quietly powers a lot of what makes your apps feel fast and responsive.

Loved this deep dive? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

See you next week with more exciting content!

Here's Something Extra for You: Exciting Job Openings 🚀

1. Member of Technical Staff - 3 Distributed systems, Nutanix : Link

2. Software Engineer (IC2), Oracle : Link

3. Software Engineer 3, Google: Link

4. Software Engineer, GenAI, Google: Link

5. Software Engineer 2, Amazon : Link

6. Software Engineer, Coinbase: Link

7. Software Engineer, Gojek : Link

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : What is HTTP ?

Don’t forget to check out the latest job openings at the end of the article!

I would like to know what type of content you want in the future. It will help me to create the right content for you. Please fill out this form to let us know

Share your Ideas!

CAP theorem is something that often confuses people in system design interviews, especially if they haven’t understood it clearly. But it’s an important concept that can really shape how you design your system.

In this post, we’ll explain what CAP theorem is, how it works, and the trade-offs involved — all in a simple way. This will help you understand it better and feel more confident in your next system design interview.

What is CAP Theorem ?

At a basic level, the CAP theorem says that in any distributed system, you can only get two out of these three things:

1. Consistency – Every node has the same data. So if you update something, all future reads from any node will give you that latest value.

2. Availability – Every request gets a response, even if it’s not the most recent data. So the system stays responsive no matter what.

3. Partition Tolerance – The system keeps running even if there’s a break in communication between parts of the system (like a network issue).

Here’s the main idea that makes CAP theorem easier to understand in interviews: In real-world distributed systems, you always need partition tolerance. Network issues are bound to happen, and your system has to deal with them.

So in most cases, CAP comes down to one simple decision: When there’s a network issue, do you want your system to stay consistent or stay available?

Let’s break this down with a simple example to understand it better.

3 Pillars of CAP

1. Consistency

Consistency means that every time you read data, you either get the most recent update — or an error if that’s not possible. All healthy nodes in the system will return the same data at the same time.

For example, if you write something to Node A, and then read from Node B, you’ll see that latest update right away.

This is really important for systems where accuracy is critical like in banking apps, where checking your balance must always show the most recent amount.

Just a heads-up — consistency in CAP theorem is not the same as the consistency in ACID databases.

Yeah, it’s a bit confusing, but they mean different things in different contexts.

2. Availability

Availability means that every request, whether it’s a read or write, gets a response. But that response might not always have the latest data.

So even if some nodes are out of sync, the system still works and stays responsive.

This is super important for apps that need to be always up and running, like online shopping sites, where showing something is better than showing nothing.

3. Partition Tolerance

Partition Tolerance means the system keeps working even if some parts of it can’t talk to each other because of a network issue.

A network partition happens when a failure splits the system into two or more groups of servers that can’t communicate.

When this happens, the system has to choose between staying consistent or staying available.

Partition tolerance is a must for distributed systems because network problems are pretty common. A partition-tolerant system can still run smoothly, even when the network isn’t perfect.

Understand Through an Example

Let’s say you have a website with two servers, one in the India and one in Europe.

Now imagine this:

• User A is in the India. They connect to the India server and update their display name on their profile.

• That update is then sent to the Europe server so both servers stay in sync.

• Later, User B (who’s in Europe) checks User A’s profile and sees the new, updated name.

Everything works smoothly because the servers can talk to each other and keep the data consistent.

But things change when there’s a network partition — the connection between the USA and Europe servers goes down. Now we face an important decision:

When User B (in Europe) tries to view User A’s profile, what should we do?

• Option A: Return an error, because we can’t be sure the data is the latest (this means choosing consistency).

• Option B: Show the last known data, even if it might be a bit outdated (this means choosing availability).

This is the heart of the CAP theorem — deciding between consistency and availability when something goes wrong in the network.

This is where the CAP theorem becomes real — we have to pick between consistency and availability.

In this case, the choice is pretty obvious: it’s better to show User B the old name than to show an error. A slightly outdated profile is still useful — an error page isn’t.

Let’s look at a few more real-world examples where systems make similar choices.

Subscribe now

Consistency Over Availability

Some systems just can’t afford to show outdated data, they need to stay consistent, even if that means being less available during issues.

If you prioritize consistency, your design might include:

• Distributed Transactions: You make sure different parts of your system (like the database and cache) stay in sync using methods like two-phase commit. This keeps data accurate, but it also adds complexity and can slow things down for users.

• Single-Node Setup: You can avoid consistency problems by using just one database. This limits how much your system can grow, but it keeps everything simple and reliable with one source of truth.

• Tech Choices that support strong consistency:

  • Traditional databases like PostgreSQL or MySQL

  • Google Spanner

  • DynamoDB (when used in strong consistency mode)

Here are a few examples of systems require consistency over availability:

• Ticket Booking Systems: Let’s say User A books seat 6A on a flight. But because of a network issue, User B still sees it as available and books it too. Now two people have the same seat — that’s a big problem.

• Online Shopping (Inventory): Imagine Amazon has just one toothbrush left. If the system shows it as available to multiple users during a network issue, it could be sold to more people than they actually have in stock.

• Financial Systems: Stock trading platforms need to show real-time data. If you see stale prices, you might place trades that don’t reflect the actual market — and that can cost people a lot of money.

Availability Over Consistency

Most systems can handle a bit of inconsistency and should focus on availability. In these cases, eventual consistency is good enough — meaning the system will become consistent over time, maybe after a few seconds or minutes.

If you prioritize availability, your design might include:

• Multiple Replicas: You can have extra read replicas with asynchronous replication, which means they may be slightly behind but can still serve requests. This improves performance and keeps the system available — even if some data is a bit outdated.

• Change Data Capture (CDC): This tracks changes in the main database and pushes updates to replicas, caches, or other systems in the background. It helps the main system stay available while the updates reach everywhere eventually.

• Tech choices that support high availability:

  • Cassandra

  • DynamoDB (when used across multiple availability zones)

  • Redis clusters

Here are a few examples of systems require availability over consistency:

• Social Media: If User A changes their profile picture, it's okay if User B still sees the old one for a little while.

• Streaming Platforms (like Netflix): If someone updates a movie’s description, it's not a big deal if some users still see the old version for a short time.

• Review Sites (like Yelp): If a restaurant changes its hours, showing the older timing briefly is still better than showing nothing.

NOTE :
The main question to ask is: “Would it really hurt if users saw slightly outdated data for a bit?”
If the answer is yes, go with consistency. If the answer is no, availability is usually the better choice.

Different Levels of Consistency

When people talk about consistency in the CAP theorem, they usually mean strong consistency where every read shows the latest write. But there are other types of consistency too, and knowing them can help you design smarter systems depending on your needs.

• Strong Consistency: Every read gives you the most recent write. This is the most reliable but also the slowest. It's needed for systems like bank accounts, where accuracy is critical. (This is the type we’ve focused on so far.)

• Causal Consistency: Events that are related always appear in the correct order. For example, comments on a post will always show up after the post itself, never before.

• Read-Your-Own-Writes: A user can immediately see their own updates, even if others can't yet. This is common in social media, where users expect to see their changes (like profile updates) right away.

• Eventual Consistency: The system will become consistent over time, but it may not be instant. This is fine for things like DNS or systems where a small delay in updates is okay. Most distributed systems use this when they prioritize availability.

Wrapping Up!

The CAP theorem is super important, it helps shape the way you think about system design, especially in interviews. And it’s something you shouldn’t ignore.

But the good news is: it doesn’t have to be complicated.

Just ask yourself one simple question: “Does every read need to return the most recent write?” If the answer is yes, go with consistency. If the answer is no, availability is usually the better choice.

Loved this deep dive? Hit a like ❤️
For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

If you have any questions or suggestions, leave a comment.

See you next week with more exciting content!

Here's Something Extra for You: Exciting Job Openings 🚀

1. Member of Technical Staff - 3 Distributed systems, Nutanix : Link

2. Software Engineer (IC2), Oracle : Link

3. Software Engineer 3, Google: Link

4. Software Engineer, GenAI, Google: Link

5. Software Engineer 2, Amazon : Link

6. Software Engineer, Coinbase: Link

7. Software Engineer, Gojek : Link

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : What are Microservices ?

I would like to know what type of content you want in the future. It will help me to create the right content for you 👇

Share your Ideas!

What is HTTP?

HTTP is a set of rules that allow computers to talk to each other over the internet.
When you open a browser and visit a website, like www.google.com, your browser sends a message to Google’s servers saying:

“Hey! Can you show me the homepage, please?”

And Google replies with:

“Sure! Here’s the content you asked for.”

This whole conversation happens using HTTP.

Think of HTTP as the language your browser uses to request data, and your server uses to respond.

Two important traits make HTTP what it is:

• Connectionless

• Stateless

Subscribe now

Real World Analogy: Ordering a burger…

Imagine walking into a fast-food restaurant:

• You walk to the counter.

• Place your order for a cheeseburger.

• Get the burger.

• Walk away.

The cashier doesn't remember you, nor does she keep the connection open for future orders.

Every time you want something new, you go back and repeat the whole process.

That’s HTTP.

• 🍽 Connectionless → You don’t keep the line open after getting the burger.

• 🧠 Stateless → The cashier doesn’t remember your last order.

How HTTP Works (Step-by-step)

Here’s how HTTP works when you open a website like google.com:

1. You type the URL in your browser.

2. Browser contacts DNS to find the actual IP address.

3. Browser sends an HTTP request to the server at that IP.

4. Server sends back an HTTP response — containing the website content.

5. The connection closes.

6. Want to visit another page? → Repeat from step 3.

It’s like sending a letter and getting a reply, no ongoing call, no memory.

HTTP is Stateless - But Why Does Google Remember Me?

If HTTP is stateless, how does Google remember you're logged in?

💡 Answer: Cookies

Cookies are small text files that your browser stores.

Here’s how they work:

• You log in to a site → Server sends back a cookie with your login info.

• That cookie is saved in your browser.

• Next time you visit the site, your browser sends that cookie back → Server recognizes you!

So even though HTTP doesn’t remember you, cookies help websites remember who you are.

HTTP Methods - How You Interact with the Server

Think of HTTP Methods like the different actions you can perform in a conversation:

The browser uses these methods to talk to the server and get things done.

HTTP Status Codes - Messages From the Server

When your browser makes a request, the server replies with a status code to indicate what happened:

These codes help developers understand what’s going wrong when something doesn’t load properly.

Advantages of Using HTTP

• Fast and lightweight – It doesn’t use much memory or CPU.

• Simple to implement – Easy for both clients and servers to work with.

• Low network load – Fewer connections = less internet traffic.

• No session tracking – Great for quick, one-time requests.

• Supports pipelining – Can send multiple requests without waiting.

Limitations of HTTP

• Not secure – Sends data in plain text (hello hackers 👀).

• Not mobile-friendly – Doesn’t handle mobile networks well.

• Poor for sensitive data – No encryption = risky for logins, payments, etc.

• Uses more power – Long data transfers can be resource-heavy.

• One request at a time – Server can get stuck waiting on slow clients.

HTTP vs HTTPS - What’s the Real Difference?

Imagine you're writing a postcard (📬).
Anyone who handles it can read everything you wrote. That’s how HTTP works — your data travels openly, without any protection.

Now imagine locking that postcard in a box 🔒 before sending it.
Only the person with the key can open and read it. That’s HTTPS — it encrypts your data, so no one else can read it, even if they intercept it.

How HTTPS works ?

• HTTPS uses security tools called SSL and TLS to scramble (encrypt) your data before sending it.

• Only the website you're talking to can unscramble (decrypt) it.

• This ensures a private and secure connection between you and the website.

The website also proves it’s trustworthy using something called an SSL certificate — like a digital ID card.

Why HTTPS is Better ?

• Secure Communication – Your data is locked while in transit.

• Data Integrity – It ensures your data isn’t changed or tampered with.

• Privacy – No one can snoop on your personal info.

• Performance – Modern HTTPS is fast and efficient.

• Trust – Browsers now mark non-HTTPS sites as “Not Secure.”

Quick Dev Tip

Open DevTools → Network Tab in your browser
👉 Load any site
👉 You’ll see every HTTP request, method, and status code

Explore it. You will learn a lot.

Wrapping Up!

HTTP might seem like a technical detail, but it’s everywhere.
Every browser, API call, and website you interact with uses HTTP under the hood.

So the next time someone says “this API is broken”. Remember: it’s probably just an HTTP request gone wrong. 😉

Loved this deep dive? For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

See you next Week with more exciting content!

Here's Something Extra for You: Exciting Job Openings 🚀

• System Performance Engineer @Google:
  https://www.linkedin.com/jobs/view/4131721557

• Software Engineer, Product @Meta:
  https://www.linkedin.com/jobs/view/4142048795

• Software Engineer 1 @Dell:
  https://www.linkedin.com/jobs/view/4145776983

• Software Engineer @LinkedIn:
  https://www.linkedin.com/jobs/view/4135579811

• Software Engineer @Microsoft:
  https://www.linkedin.com/jobs/view/4099719491

• Software Engineer - Frontend @HackerEarth:
  https://www.linkedin.com/jobs/view/4143880403

• Software Developer 3 @Oracle:
  https://www.linkedin.com/jobs/view/4104207974

• Software Development Engineer - II - Frontend @Meesho:
  https://www.linkedin.com/jobs/view/4144401401

Leave a comment

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : What are Microservices ?

I would like to know what type of content you want in the future. It will help me to create the right content for you 👇

Share your Ideas!

Imagine walking into a luxury hotel. You don’t need to know where housekeeping or maintenance is located, right? Instead, you check in at the front desk, and they handle everything from room assignments to special requests. In the world of microservices, the API Gateway plays that role for client requests.

In simple terms:

• Single Entry Point: It’s the one door through which all your app’s requests come in.

• Traffic Controller: Just like the front desk directs guests, the API Gateway routes each request to the right backend service.

• Middleware Manager: It handles all the routine but crucial tasks like authentication, rate limiting, and logging, so your services can focus on what they do best.

Core Responsibilities

Let’s walk through the key things an API Gateway does, step by step.

1. Request Validation

Before anything else, the API Gateway ensures that every incoming request is properly formatted and contains the necessary information. Think of it as checking that a guest has all the right documents before they even step into the hotel. If something's missing, say, a required API key or a well-formed request, the gateway can quickly send an error response, saving time and resources for your backend services.

routes:
  - path: /clients/*
    service: client-management
    port: 8080
  - path: /purchases/*
    service: purchase-service
    port: 8081
  - path: /transactions/*
    service: transaction-service
    port: 8082

2. Middleware Magic

After validation, the gateway jumps into action with its middleware features.
Here’s what it typically handles:

• Authentication: Verifies that the requester is who they say they are (like checking an ID at the front desk).

• Rate Limiting: Prevents any one client from overwhelming your system—imagine limiting the number of items a guest can order from the minibar.

• Logging & Monitoring: Keeps an eye on all the requests, which is super helpful for troubleshooting and performance insights.

• Other Tasks: It can also manage SSL termination, compress responses, handle CORS headers, and more.

By centralizing these tasks, your individual services remain lean and focused.

// Client sends an HTTP POST request to create a new order
POST /orders
Content-Type: application/json

{
  "userId": "123",
  "productId": "456",
  "quantity": 3
}

// API Gateway transforms this into an internal gRPC call
orderService.createOrder({ userId: "123", productId: "456", quantity: 3 })

// Gateway transforms the gRPC response into JSON and returns it to the client over HTTP
{
  "orderId": "789",
  "status": "confirmed",
  "deliveryDate": "2025-04-01"
}

3. Intelligent Routing

The heart of the API Gateway is its routing capability. It looks at details like the URL path, HTTP method, and headers to decide which backend service should handle the request. For example, a request to /users/profile might be routed to your user service, while /orders might go to your order processing system.
This setup means your clients don’t have to deal with multiple endpoints, everything goes through one neat channel.

4. Backend Communication & Response Transformation

Once a request is routed, your backend services do their magic and send back a response. The API Gateway then transforms this response into a client-friendly format. For instance, if your services communicate internally using a different protocol, the gateway can convert it back to standard HTTP/JSON before sending it out. It’s like having a translator at the front desk who ensures everyone understands each other perfectly.

5. Caching for Speed

To improve performance, the API Gateway can cache responses for frequently requested data. If a guest asks for the same hotel information repeatedly, the front desk can quickly hand out a brochure instead of re-preparing all the details from scratch. This caching mechanism helps reduce load and speed up response times.

Subscribe now

Scaling the API Gateway

As your user base grows, so does the need for your gateway to handle increased traffic. Here’s how you can scale:

• Horizontal Scaling: Since API Gateways are typically stateless, you can add more instances behind a load balancer to distribute incoming requests efficiently.

• Global Distribution: For apps with users around the world, deploying API Gateways in multiple regions can reduce latency by directing users to the nearest instance.

Choosing the Right API Gateway

When it comes to implementation, you have plenty of options:

• Managed Services: AWS API Gateway, Azure API Management, and Google Cloud Endpoints offer fully managed solutions that integrate seamlessly with their ecosystems.

• Open Source: Tools like Kong, Tyk, and Express Gateway give you more control, especially if you're running services on-premises or prefer a customizable approach.

When to Use an API Gateway

Here’s a quick rule of thumb:

• Microservices Architecture: If your system is composed of multiple microservices, an API Gateway is almost indispensable. It keeps your client interactions clean and your internal services decoupled.

• Simple Client-Server Architecture: If you’re working with a straightforward monolithic design, adding an API Gateway might complicate things unnecessarily.

In system design interviews, a good tip is to mention that you’d add an API Gateway to handle routing and basic middleware tasks and then confidently move on to the more interesting parts of your design.

Wrapping Up!

The API Gateway is more than just a routing tool, it’s the unsung hero that manages the chaos of modern distributed systems. By centralizing key functions like validation, authentication, routing, and caching, it allows your microservices to shine without getting bogged down by repetitive tasks.

Loved this deep dive? For more simple explanations, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

See you next Monday with more exciting content!

Scortier, Signing Off!

Here's Something Extra for You: Exciting Job Openings 🚀

• Software Engineer, Rubrik

• Software Engineer Fullstack, Linkedin

• Software Engineer 2, Amazon

• Software Engineer 2, Vimeo

• Software Engineer, Search, Postman

Leave a comment

Welcome to Hello Engineer, your weekly guide to becoming a better software engineer! No fluff - pure engineering insights.

You can also checkout : What is DNS ? The Simplest Explanation

I would like to know what type of content you want in the future. It will help me to create the right content for you. Please fill out this form to let us know

Fill Form

Ever Wondered How Netflix Handles 200+ Million Users ?

Picture this: You’re binge-watching Stranger Things on Netflix. Suddenly, the “Recommended for You” section updates, your watch history syncs, and your payment for the next month processes seamlessly. All of this happens in the background, without a single glitch.

How?

The answer lies in microservices.

But what are microservices? And why do companies like Netflix swear by them, while others like Google stick to monolithic architectures? Let’s dive in.

What are Microservices ?

Imagine you’re building a city. A bustling, thriving city with millions of residents. Now, think of your city’s services:

• Water supply

• Electricity grid

• Public transportation

• Healthcare

Each of these services operates independently. If the water supply goes down, the electricity grid keeps running. If public transportation halts, hospitals still function.

Microservices work the same way.

Instead of building one giant, monolithic application (where everything is interconnected and a single failure can bring down the entire system), microservices break your app into smaller, independent “services.” Each service handles a specific function, like:

• User authentication

• Payment processing

• Search functionality

• Notifications

These services communicate with each other but are developed, deployed, and scaled independently.

Why Microservices? Let’s Talk Monoliths First

Before microservices, there were monolithic architectures. Think of a monolith as a giant, all-in-one machine. Everything—your database, business logic, user interface—is bundled into a single codebase.

The Good:

• Simple to develop: Everything is in one place.

• Easy to deploy: One build, one deployment.

• Fast performance: No network calls between services.

The Bad:

• Scalability issues: Want to scale just the search feature? Too bad, you have to scale the entire app.

• Team dependencies: Multiple teams working on the same codebase? Chaos ensues.

• Single point of failure: One bug can crash the entire system.

The Ugly:

• Tech lock-in: Stuck with the same programming language and framework forever.

Enter Microservices: The Modular Approach

Microservices solve these problems by breaking the monolith into smaller, self-contained units.

Let’s take Amazon as an example.

Amazon isn’t one giant app. It’s a collection of microservices:

• Search Service: Handles product searches.

• Cart Service: Manages your shopping cart.

• Payment Service: Processes payments.

• Recommendation Service: Suggests products you might like.

Each service is developed by a separate team, using the best tech stack for the job. The Search Service might use Python for its machine learning algorithms, while the Payment Service uses Java for its robustness.

The Benefits:

• Independent scaling: Only scale the services that need it.

• Faster development: Teams work in parallel without stepping on each other’s toes.

• Resilience: If one service fails, the rest keep running.

• Tech flexibility: Use the right tool for the job.

Challenges with Microservices

Microservices come with their own set of challenges:

1. Complexity: Managing multiple services, databases, and deployments can get messy.

2. Communication: Services need to talk to each other, often over a network. This introduces latency and potential failures.

3. Debugging: Tracing an issue across multiple services is like finding a needle in a haystack.

4. Infrastructure overhead: You’ll need tools for service discovery, load balancing, and monitoring.

Monoliths vs. Microservices: Who Wins?

It’s not a one-size-fits-all answer.

• Monoliths are great for small teams and simple apps. They’re fast, easy to build, and require less overhead.

• Microservices shine for large, complex systems with multiple teams. They offer flexibility, scalability, and resilience.

Fun fact: Google still uses a monolithic architecture for its search engine. Why? Because it works for them. On the other hand, Netflix relies heavily on microservices to handle its massive scale and ever-evolving features.

Atlassian Blog on differences between monolith and microservice : https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Now that you know what microservices are, here’s a question for you :

If you were building the next big social media app, would you go monolithic or microservices? Why?

Hit reply and let me know your thoughts!

Enjoyed this explanation? For more simple, useful insights on coding, system design, and tech trends, Subscribe To My Newsletter! 🚀

See you next Monday with more exciting content!

Scortier, Signing Off!

Bonus Section 🚀: Top Books to Master System Design

1. Designing Data-Intensive Applications by Martin Kleppmann

2. The System Design Primer by Donne Martin

3. System Design Interview Part 1 and 2 by Alex Xu

4. Distributed Systems: Principles and Paradigms by Andrew S. Tanenbaum

Leave a comment