DEV Community: Sabita kumari

System Design From Scratch: The Components That Actually Run Production Systems

Sabita kumari — Thu, 09 Apr 2026 20:53:10 +0000

You open amazon.com. A product page loads in under a second. Behind that single page load, your request hit a DNS server, bounced through a CDN edge node, passed a rate limiter, got distributed by a load balancer, routed by an API gateway, processed by a microservice, checked a Redis cache, and maybe — maybe — touched an actual database.

That's system design. Not theory. Not whiteboard boxes. The actual machinery that keeps websites alive when millions of people use them at the same time.

Here's how each piece works, why it exists, and when you need it.

The Client-Server Relationship and DNS

Everything starts with two things: a client and a server.

The client is whatever device makes the request — your phone, laptop, a smart fridge, doesn't matter. The server is a machine that runs 24/7 with a public IP address, sitting in a data center somewhere, waiting for requests.

The problem is that IP addresses look like 10.5.8.2. Nobody remembers that. So we have DNS — the Domain Name System — which is basically a global phone book. You type amazon.com, your browser asks a DNS server "what's the IP for this?", and the DNS server responds with 10.5.8.2. Your browser then connects directly to that IP.

That lookup process is called DNS resolution. It happens before anything else, every single time.

Vertical vs. Horizontal Scaling

Your server has 2 CPUs and 4 GB of RAM. Traffic grows. The machine starts choking. What do you do?

Vertical scaling (scale up): Upgrade the machine. Add more RAM, more CPU cores, faster disks. The problem? You usually need to restart the machine to do this. That means downtime. For a hobby project, fine. For Amazon during Black Friday, absolutely not. There's also a hard ceiling — you can only make a single machine so powerful before physics says no.

Horizontal scaling (scale out): Add more machines. Instead of one beefy server, run three identical servers in parallel. If one goes down, the other two keep serving traffic. No restart needed. No ceiling — just add another machine.

This is why every serious production system uses horizontal scaling. You get zero-downtime deployments, redundancy if a server dies, and linear capacity growth.

But horizontal scaling creates a new problem: if you have three servers, how does the client know which one to talk to?

Load Balancers

A load balancer sits in front of your servers and distributes incoming traffic across them. The client never talks to the servers directly — it talks to the load balancer, and the load balancer decides which server handles each request.

The simplest distribution algorithm is Round Robin: request 1 goes to server A, request 2 to server B, request 3 to server C, then back to A. More sophisticated load balancers also run health checks — they periodically ping each server, and if one stops responding, they stop sending it traffic until it recovers.

In AWS, this is the Elastic Load Balancer (ELB). Most teams don't build their own. Managed load balancers handle SSL termination, sticky sessions, and connection draining — so your team can focus on the application.

API Gateways and Microservices

As your application grows, you stop running everything in one monolithic codebase. Authentication becomes its own service. Orders become their own service. Payments get their own service. This is microservice architecture — each business function runs independently, with its own database, its own deployment pipeline, and its own team.

The question becomes: how does the client know which service to call? It doesn't. That's what the API gateway handles.

An API gateway is a single entry point that routes requests based on the URL path. A request to /auth goes to the authentication service. A request to /orders goes to the order service. A request to /payments goes to the payment service. The client only knows about one URL — the gateway handles the rest.

It also acts as a reverse proxy, meaning the internal services are never exposed to the public internet. The gateway is the only thing with a public IP. Everything behind it is internal.

The load balancer, API gateway, and microservices flow:

Asynchronous Communication and Queues

Some tasks don't need to happen in real time. If a user places an order and the system needs to send a confirmation email, that email doesn't need to go out in the same millisecond. It can happen 2 seconds later. Or 10 seconds later. The user won't notice.

This is where asynchronous communication comes in. Instead of the main server sending the email itself (and blocking until it's done), it pushes a task into a queue — a first-in, first-out list of jobs waiting to be processed. Background workers pull tasks from the queue at their own pace.

AWS SQS is the most common managed queue. The pattern is simple: producer pushes a message, consumer pulls it, processes it, and acknowledges it. If the consumer crashes before acknowledging, the message goes back into the queue for another worker to pick up.

This matters when the task is heavy. Imagine sending a million promotional emails. If the main server tried to send them synchronously, it would be stuck for hours. With a queue and 10 background workers, each worker handles 100,000 emails in parallel. The main server moved on the instant it pushed the tasks.

Event-Driven and Fan-Out Architecture

Here's a common scenario: a payment succeeds, and you need to send an email confirmation, an SMS, and a WhatsApp message. Three actions from one event.

You could have the payment service call each notification system directly. But that creates tight coupling — if the SMS service is slow, it blocks the payment response. If someone adds a push notification later, you have to modify the payment service code.

The better approach is pub-sub (publish-subscribe). The payment service publishes a "payment succeeded" event to a topic (AWS SNS, for example). Three separate queues are subscribed to that topic — one for email, one for SMS, one for WhatsApp. Each queue has its own worker.

This is a fan-out architecture. One event fans out to multiple independent channels. The critical benefit: if the SMS worker crashes, it retries on its own. The email and WhatsApp workers don't know or care. No cascading failures. Each channel is fully independent.

The async processing and fan-out architecture:

Rate Limiting

Without rate limiting, a single bad actor (or a botnet) can flood your servers with millions of requests and take your system down. This is a DDoS attack, and it happens constantly.

Rate limiting caps the number of requests a user or IP can make within a time window. Two common algorithms:

Token bucket: Each user has a bucket that fills with tokens at a fixed rate (say, 5 per second). Each request costs one token. If the bucket is empty, the request is rejected. This allows short bursts — if a user hasn't made requests in a while, their bucket is full and they can fire several at once.

Leaky bucket: Requests enter a queue that drains at a fixed rate. Excess requests overflow and get dropped. This produces a perfectly steady output regardless of input burstiness.

Most production systems implement rate limiting at the load balancer or API gateway level, before requests even reach your services.

Database Scaling: Read Replicas

Your database is a single machine. Most web applications read far more than they write — a product page might get viewed 10,000 times for every one inventory update. So the database bottleneck is usually reads, not writes.

The fix is read replicas. You keep one primary node that handles all write operations. Every write gets replicated to one or more read replicas. Your application sends reads to replicas and writes to the primary. This spreads the load across multiple machines.

The tradeoff is replication lag — there's a small delay (usually milliseconds) between a write hitting the primary and propagating to replicas. For most applications, this is fine. For financial transactions where you need to read your own write immediately, you route that specific read to the primary.

Caching with Redis

Even with read replicas, database queries take time. A cache sits between your application and the database, storing the results of frequent queries in memory.

Redis is the standard. It's an in-memory key-value store. When your application needs data, it checks Redis first. Cache hit? Return the result instantly — no database query needed. Cache miss? Query the database, store the result in Redis for next time, and return it.

For a product page that gets 50,000 views per hour, this means 1 database query and 49,999 cache hits. The database barely notices.

The hard part of caching is invalidation — knowing when to throw away stale data. If a product's price changes, the cached version is wrong until it expires or gets manually evicted. Most teams use a TTL (time-to-live) of 30 seconds to a few minutes, depending on how stale the data can be.

CDNs and Global Optimization

Your servers are in Virginia. A user in Mumbai is 13,000 km away. Even at the speed of light, that round trip adds latency. For static content — images, CSS files, JavaScript bundles, product photos — there's no reason to fetch them from Virginia every time.

A CDN (Content Delivery Network) copies your static content to edge locations around the world. Amazon CloudFront has edge nodes in Mumbai, London, São Paulo, Tokyo, and dozens of other cities. When the Mumbai user requests a product photo, the CDN serves it from the Mumbai edge — no round trip to Virginia.

CDNs use anycast routing, which means the same IP address resolves to different physical servers depending on the user's location. The network automatically routes each user to the closest edge node.

If the content is already cached at the edge, it's returned immediately. If not, the edge fetches it from the origin server, caches it, and serves it. Future requests from that region hit the cache instead of the origin.

For a global e-commerce site, CDNs cut page load times from seconds to milliseconds for users far from the data center. They also reduce bandwidth costs on the origin server, because most requests never reach it.

Database scaling, caching, and CDN:

Putting It All Together

Here's the complete request flow when someone opens a product page:

DNS resolves amazon.com to an IP address
CDN serves static assets (images, CSS, JS) from the nearest edge
Rate limiter checks if the user has exceeded their request quota
Load balancer picks a healthy server and forwards the request
API gateway routes /products/123 to the product service
Product service checks Redis cache for the product data
Cache miss → query a read replica database
If a purchase happens → payment service publishes an event
Pub-sub fans out to email, SMS, WhatsApp queues
Background workers process each notification independently

Every component exists because a single server running everything stops working at scale. DNS gives you human-friendly addresses. Horizontal scaling gives you redundancy. Load balancers distribute traffic. API gateways route to services. Queues decouple heavy tasks. Caching reduces database load. CDNs cut latency. Rate limiting protects the system.

None of this is optional at scale. It's the reason that page loads in under a second.

50 Claude Code Best Practices Every AI Engineer Should Know

Sabita kumari — Wed, 08 Apr 2026 03:02:33 +0000

50 Claude Code tips to help you build with Claude that nobody talks about.

Over the past 24 hours, I read the new Claude Code best practices document so you don't have to.

New Best Practices for Claude Code

I've extracted all the best practices + added some of my own from personal experience to compile the ultimate list of Claude Code best practices.

This list also includes various Claude Code tools + learning resources.

Rapid-fire style - let's go.

Foundational Tips

50. Clear Task Framing - State exactly what you want Claude to do before anything else.

49. Front Load Instructions - Always put the most important instruction at the very top of the prompt.

48. Give Claude a way to verify its work - Include tests, screenshots, or expected outputs so Claude can check itself. This is the single highest-leverage thing you can do.

47. Prompt Structure Tip - To make the last few tips practical, I like this prompting structure:
[Role] + [Task] + [Context]

46. Chrome Extension Tip - UI changes can be verified using the Claude Chrome extension. It opens a browser, tests the UI, and iterates until the code works.

45. Explore first, then plan, then code - Research (this process can include other LLMs), then enter Plan Mode, then switch back to normal mode to execute code.

44. Provide specific context in your prompts - The more precise your instructions, the better. Claude can only infer context.

43. Assume Zero Context - Assume Claude knows nothing about your project. Tell it everything it needs to know.

42. Rich Context - Use @ to link files, data, and images.

41. Claude.MD Tip - Run /init to generate a starter CLAUDE.md file for your current project.

Projects & Skills Use

40. Project Instructions - Use project-level instructions to define long-term behavior instead of repeating prompts.

39. Project Memory - Edit the "Memory" tab to control exactly what Claude should retain or ignore over time (this works in projects as well).

38. Claude Skills - Use them to turn repeatable workflows into Skills instead of re-prompting.

37. Skill From Examples - Paste a great output and ask Claude to turn it into a reusable Skill. You can even upload screenshots and ask Claude to replicate it; turn it into a skill (an easy way to create elite skills).

36. Skill Versioning - Duplicate and version Skills as you refine workflows instead of editing live ones.

35. Project Hygiene - Regularly prune memory, files, and instructions to avoid drift.

34. Project Context Bleed - Separate projects for unrelated workstreams to prevent context bleed.

33. Claude Skills Repo - A library of 80,000+ Claude Skills: https://skillsmp.com/

32. Claude Skills Library - A cool website with plug-and-play Skills and more: https://mcpservers.org/claude-skills

31. Project Memory Location - Project memory can be stored in either ./CLAUDE.md or ./.claude/CLAUDE.md.

Underrated Mini Tips (most people don't know about these)

30. Model Stacking - Use other LLMs to plan your projects and generate advanced mega prompts before ever opening Claude Code — this strategy also saves tokens from Plan Mode.

29. Create custom subagents - Define specialized assistants in .claude/agents/ that Claude can delegate to for isolated tasks.

28. Output Scoring - Ask Claude to score its answer against your pre-defined success criteria.

27. Install Plug-ins - Run /plugin to browse the marketplace. Plugins add skills, tools, and integrations without any configuration.

26. Claude Code taught IN Claude Code - A course that teaches you Claude Code directly IN Claude Code: https://ccforeveryone.com/

25. Claude Interviews - For larger projects, have Claude interview you first. Start with a minimal prompt and ask Claude to interview you using the AskUserQuestion tool.

24. Correct Often - Course-correct Claude often. The moment it starts going off track, stop (ESC to stop Claude mid-action).

23. Clear - Run /clear to start a clean session.

22. Rewind - Double-tap ESC or /rewind to open checkpoint menu.

21. Run Multiple Sessions - There are two main ways to run parallel sessions:

Claude Desktop: Manage multiple local sessions visually. Each session gets its own isolated worktree.
Claude Web: Run on Anthropic's secure cloud infrastructure in isolated VMs.

Debugging, Error Handling, Common Failure Patterns

20. Step Isolation - Re-run only the broken step instead of regenerating everything.

19. Error Reproduction - Ask Claude to intentionally reproduce the failure to understand it.

18. Rollback Prompts - Revert to the last known good prompt and reapply changes one at a time.

17. Over-Specified CLAUDE.md - If your CLAUDE.md is too long, Claude ignores half of it because important rules get lost in the noise.

Fix: Ruthlessly prune. If Claude already does something correctly without the instruction, delete it or convert it to a hook.

16. Don't make this mistake - You start with one task, then ask Claude something unrelated, then go back to the first task. Context is full of irrelevant information.

Fix: /clear between unrelated tasks.

15. Over-Correcting - Claude does something wrong, you correct it, it's still wrong, you correct again. Context is polluted with failed approaches.

Fix: After two failed corrections, /clear and write a better initial prompt incorporating what you learned.

14. Step-by-Step Replay - Have Claude walk through how it generated the answer line by line.

13. The Infinite Exploration - You ask Claude to "investigate" something without scoping it. Claude reads hundreds of files, filling the context.

Fix: Scope investigations narrowly or use subagents so the exploration doesn't consume your main context.

12. Debugging Project - Create an AI project dedicated to debugging code (Grok 4 Heavy is good at debugging).

11. Context Window Management - Claude's context window fills up fast. As this happens, Claude may start forgetting earlier instructions. This page will help you eliminate that problem: https://code.claude.com/docs/en/costs#reduce-token-usage

Final Tips

10. Notion Database - Connect your Notion database to Claude to store your best & most commonly used prompts.

9. Learn Claude Code in Action - Anthropic's learning resources: https://www.anthropic.com/learn

8. Claude Courses - Courses from Coursera: https://www.anthropic.com/learn

7. Boris' Set Up - How the creator of Claude Code maximises Claude Code: Boris' Claude Code Setup Cheatsheet

6. Claude Code Best Practices (DOC) - Link to the latest doc: https://code.claude.com/docs/en/best-practices

5. Safe Autonomous Mode - Use claude --dangerously-skip-permissions to bypass all permission checks and let Claude work uninterrupted. This works well for workflows like fixing lint errors or generating boilerplate code.

4. Slow & Steady - Take your time. Especially if building a serious workflow. Plan. Plan. Plan. THEN, execute.

3. Claude Superpowers - A GitHub Repo of Claude Code superpowers: https://github.com/obra/superpowers

2. Hooks - Best for actions that must happen every time with zero exceptions.

1. How to Extend Claude Code - Anthropic's Guide: https://code.claude.com/docs/en/features-overview