DEV Community: Daniel Keya

Day 5 of 30: Message Queues and Why Not Everything Needs an Instant Response

Daniel Keya — Sat, 11 Jul 2026 18:01:53 +0000

Day 1: the big picture. Day 2: databases. Day 3: caching. Day 4: load balancing, and how the load balancer itself becomes a new single point of failure. Today: message queues and asynchronous processing — a topic that quietly reframed how I think about "handling a request."

The Assumption I Didn't Know I Had

Up until today, my mental model of a system was: request comes in, server does the work, response goes out, all in one continuous chain. Synchronous, start to finish.

Today's lesson was basically: that assumption breaks down the moment any part of the work is slow, unreliable, or doesn't need to happen right now. Sending a confirmation email, resizing an uploaded image, generating a report, notifying a third-party service — none of that needs to block the response the user is waiting on.

What a Message Queue Actually Does

A message queue sits between two parts of a system — a producer that creates a task or event, and a consumer that processes it — and holds messages in between until the consumer is ready. The producer doesn't wait around for the consumer to finish; it just drops the message in the queue and moves on.

That single shift — not waiting — is what decoupling really means in practice. The producer and consumer don't need to run at the same speed, be available at the same time, or even know much about each other. They just agree on the shape of the message.

Why This Matters for Scaling

A few reasons this clicked for me as a system design concept, not just an engineering convenience:

Load leveling — if a sudden burst of requests comes in, the queue absorbs the spike. Consumers can keep processing at a steady rate instead of getting overwhelmed all at once. This is the async equivalent of what caching does for reads.
Failure isolation — if the consumer service goes down temporarily, messages just wait in the queue instead of being lost or crashing the producer. When the consumer comes back up, it picks up where it left off.
Independent scaling — producers and consumers can scale separately. If processing is the bottleneck, you add more consumers without touching the producer at all.

This ties directly back to horizontal scaling from Day 1 — message queues are one of the main tools that make horizontal scaling of background work practical, not just scaling the request-handling servers.

Delivery Guarantees: The Part That Gets Complicated Fast

I expected this section to be simple. It was not. Queues generally offer one of a few delivery guarantees:

At-most-once — a message is delivered zero or one times. Fast, but messages can be lost.
At-least-once — a message is guaranteed to be delivered, but might be delivered more than once. Common default, but it means consumers need to be idempotent — processing the same message twice shouldn't cause duplicate side effects (e.g., charging a customer twice).
Exactly-once — the message is delivered exactly one time, no duplicates, no loss. Sounds ideal, but it's genuinely hard to guarantee in a distributed system and usually comes with real performance cost.

The idempotency point stuck with me the most. It's not enough to just add a queue — the consumer logic has to be written defensively, because "at-least-once" is the realistic default in most systems, not "exactly-once."

Queue vs. Pub/Sub

I also drew a distinction I'd been fuzzy on:

Message queue (point-to-point) — each message is processed by exactly one consumer. Good for distributing discrete units of work, like "process this uploaded file."
Pub/Sub (publish-subscribe) — a message is broadcast to all subscribers interested in that event. Good for things like "notify every service that cares that an order was placed" — inventory, billing, and notifications can all react independently to the same event.

Same underlying idea (decoupled, asynchronous communication), but the delivery pattern is fundamentally different depending on whether you need one consumer or many.

What Clicked Today

The biggest mental shift: not every part of a system needs to run inside the request-response cycle. Deciding what's synchronous and what's asynchronous is itself a design decision — and getting it right is often what separates a system that stays responsive under load from one that falls over the moment traffic spikes.

It also reinforced something from Day 3 and Day 4: decoupling components (via caching, load balancers, or queues) keeps showing up as the general strategy for making a system resilient. Different tools, same underlying move.

Tomorrow

Next up: API design and communication patterns — REST vs. GraphQL vs. gRPC, and how services actually talk to each other once you've got more than one of them.

If you've built something with a message queue, I'd love to hear how you handled idempotency — that feels like the kind of thing that's easy to get wrong quietly.

This is part of a 30-day series on learning system design from scratch. Catch up on Day 1, Day 2, Day 3, and Day 4 if you missed them.

title: Day 4 of 30: Load Balancing and the Single Point of Failure Problem

Daniel Keya — Wed, 08 Jul 2026 20:21:42 +0000

Day 1: the big picture. Day 2: databases. Day 3: caching, and how it's really a consistency problem in disguise. Today: load balancing — how traffic actually gets spread across servers, and the ways that can quietly go wrong.

Why Load Balancers Exist

Once you've horizontally scaled (Day 1 flashback) and have multiple servers instead of one, something needs to decide which server handles which request. That's the load balancer's job: sit between the client and your fleet of servers, and distribute incoming traffic so no single server gets overwhelmed while others sit idle.

It sounds simple — "just spread the requests out" — but how you spread them out turns out to matter a lot.

Load Balancing Algorithms

I went through the main ones:

Round robin — requests go to servers in sequence, one after another. Simple, but doesn't account for server load — if one request is expensive and another is cheap, round robin doesn't know or care.
Least connections — send the next request to whichever server currently has the fewest active connections. More adaptive than round robin, especially when requests vary a lot in how long they take.
Weighted round robin / weighted least connections — same ideas as above, but servers with more capacity get proportionally more traffic. Useful when your fleet isn't made of identical machines.
IP hash — the client's IP determines which server it's routed to, so the same client tends to land on the same server. This matters for session persistence (also called "sticky sessions") — some applications need a user's requests to keep hitting the same server, e.g., if session data is stored locally on that server instead of in a shared store.

The thing that stood out: there's no universally "best" algorithm. Round robin is fine when requests are roughly uniform. Least connections is better when they're not. IP hash matters when statefulness matters. It's another trade-off decision, not a default setting.

Layer 4 vs. Layer 7 Load Balancing

This distinction took me a minute to really get:

Layer 4 (transport layer) load balancers route based on IP address and port, without looking at the actual content of the request. Faster, simpler, but less flexible.
Layer 7 (application layer) load balancers can inspect the actual request — HTTP headers, URL paths, cookies — and make smarter routing decisions, like sending /api/video traffic to one set of servers and /api/search to another. More flexible, but more overhead per request.

This maps neatly onto the classic latency vs. flexibility trade-off from Day 1: Layer 4 is faster because it knows less; Layer 7 is smarter because it does more work per request.

Health Checks: How the Load Balancer Knows What's Alive

A load balancer is useless if it keeps sending traffic to a server that's already down. Health checks solve this — the load balancer periodically pings each server (or checks a dedicated health endpoint), and stops routing traffic to any server that fails to respond. This was a good reminder that load balancing isn't just about distribution, it's also about failure detection — the load balancer is quietly doing double duty as a monitoring system.

The Load Balancer Becomes a Single Point of Failure

Here's the part that really made me stop and think: I spent three days learning how to avoid single points of failure by scaling horizontally — only to introduce one giant new single point of failure sitting in front of all those servers. If the load balancer itself goes down, it doesn't matter how many healthy backend servers you have.

The common fix is to not have just one load balancer — instead, you run multiple load balancer instances behind something like DNS round robin or a floating/virtual IP, so there's no single machine the entire system depends on. It's a very "turtles all the way down" realization: every layer you add to solve a scaling problem can itself become the next bottleneck or failure point if you don't also scale and replicate that layer.

What Clicked Today

Load balancing isn't just "spread traffic evenly." It's a small system of its own, with its own trade-offs (routing algorithm, OSI layer, statefulness) and its own failure modes (the load balancer itself needs redundancy). I'm noticing a theme across all four days now: every solution to a scaling problem introduces a new, smaller version of the same problem one layer up.

Tomorrow

Next up: message queues and asynchronous processing — why not everything needs to happen in the request-response cycle, and how queues help decouple services from each other.

If you've dealt with a load balancer misconfiguration that caused uneven traffic or a nasty outage, I'd love to hear about it — feels like exactly the kind of thing that's obvious in hindsight and invisible beforehand.

This is part of a 30-day series on learning system design from scratch. Catch up on Day 1, Day 2, and Day 3 if you missed them.

Day 3 of 30: Caching, and Why Invalidation Really Is That Hard

Daniel Keya — Tue, 07 Jul 2026 20:52:07 +0000

Recap

Day 1 was the big picture (client-server, scaling, latency vs. throughput). Day 2 went into databases (SQL vs. NoSQL, replication, sharding). Today's topic was one I thought I already understood: caching. Turns out I only understood the easy 20% of it.

Why Caching Exists

The core idea is simple: fetching data is expensive (database queries, network calls, computation), so you store a copy of the result somewhere faster and cheaper to access, and serve from that copy instead of redoing the work every time.

But "store a copy somewhere faster" hides a lot of decisions: where do you store it, how long do you keep it, and how do you know when that copy is no longer accurate?

Where Caches Live

I mapped out the different layers where caching shows up in a typical system, and it's more places than I expected:

Client-side caching — browser cache, mobile app cache. Avoids hitting the network at all.
CDN caching — caching static assets (images, scripts, videos) geographically close to the user.
Application-layer caching — an in-memory store like Redis or Memcached sitting between your app server and your database.
Database caching — query result caching or buffer pools built into the database itself.

The pattern I noticed: the closer the cache is to the user, the faster it is, but the more stale it's likely to become and the harder it is to invalidate reliably.

Caching Strategies

A few patterns kept coming up:

Cache-aside (lazy loading) — the application checks the cache first; on a miss, it fetches from the database and writes the result to the cache. Simple, and only caches what's actually requested, but the first request always pays the full cost.
Write-through — data is written to the cache and the database at the same time. Keeps the cache consistent, but adds latency to every write.
Write-behind (write-back) — data is written to the cache immediately and to the database asynchronously later. Fast writes, but riskier if the cache fails before the write reaches the database.

None of these is universally "correct." Cache-aside is the one I'd reach for by default, but write-through makes sense when staleness is unacceptable, and write-behind makes sense when write throughput matters more than durability guarantees.

Cache Invalidation: The Actually Hard Part

This is where the famous line clicked for me: there really are only two hard problems in computer science — cache invalidation, naming things, and off-by-one errors (the joke itself is a joke about how hard naming and counting things are). Invalidation is hard because you're trying to answer "has the source of truth changed?" without constantly re-checking the source of truth, which would defeat the point of caching in the first place.

The strategies I looked at:

TTL (time-to-live) — the cache entry just expires after a fixed time. Simple, predictable, but you're always trading off freshness against cache-hit rate.
Explicit invalidation — when the underlying data changes, the application actively tells the cache to drop or update that entry. More accurate, but adds coupling between every write path and the cache layer.
Event-based invalidation — changes publish an event (e.g., through a message queue), and any cache watching that event invalidates itself. More scalable across multiple services, but adds infrastructure and a new failure mode: what if the event never arrives?

Cache Stampede — A Failure Mode I Hadn't Considered

One thing that stood out: what happens when a popular cache entry expires and a huge number of requests hit the database at the exact same moment because they all missed the cache simultaneously? This is called a cache stampede (or thundering herd), and it's a good example of how a cache — a tool meant to protect your database — can end up hammering it hardest at the worst possible moment if you're not careful. Mitigations like staggered expiration times or "locking" so only one request repopulates the cache while others wait came up as common fixes.

What Clicked Today

Caching looks like a performance optimization on the surface, but it's really a consistency problem wearing a performance-optimization costume. Every caching decision is really a decision about how stale you're willing to let your data be, and for how long, in exchange for speed.

That's the same trade-off shape I kept running into on Day 1 (CAP theorem) and Day 2 (replication). It's starting to feel like most of system design is a small number of trade-offs showing up over and over in different clothes.

Tomorrow

Next up: load balancing — how traffic actually gets distributed across servers, different load balancing algorithms, and where load balancers themselves become a single point of failure if you're not careful.

If you've been burned by a cache invalidation bug in production, I'd genuinely love to hear the story — those tend to be the most memorable ones.

This is part of a 30-day series on learning system design from scratch. Catch up on Day 1 and Day 2 if you missed them.

Day 2 of 30: Databases, Replication, and Sharding published: false tags: systemdesign, beginners, learning, databases

Daniel Keya — Mon, 06 Jul 2026 16:25:47 +0000

Recap

Yesterday was about the big picture — client-server architecture, scaling, latency vs. throughput, and a first look at the CAP theorem. Today I went one layer deeper: databases, and specifically, how they hold up when a system needs to scale.

This turned out to be a bigger topic than I expected. I thought "SQL vs. NoSQL" would be the whole day. It was maybe a third of it.

SQL vs. NoSQL: Less "Which Is Better," More "Which Fits"

I used to think of this as a binary choice where one option was obviously modern and the other outdated. That's the wrong frame. It's really about what shape your data takes and how you need to query it.

SQL (relational) databases — think PostgreSQL, MySQL:

Structured data with defined relationships
Strong consistency guarantees (ACID transactions)
Great when your data has clear relationships and you need to enforce integrity (e.g., financial systems, orders tied to users tied to inventory)

NoSQL databases — think MongoDB, Cassandra, DynamoDB:

Flexible or schema-less data models
Built to scale horizontally more naturally
Great for unstructured or fast-changing data, high write throughput, or massive scale where strict consistency can be relaxed

The real takeaway: the choice isn't about which database is "better" — it's about which trade-offs your system can tolerate. A banking system probably shouldn't sacrifice consistency for speed. A social media feed's like counter probably can.

Replication: Copies for Reliability and Speed

Replication means keeping copies of the same data on multiple machines. I looked at two common patterns:

Leader-follower (master-replica) replication — one node handles writes, and changes propagate to follower nodes that mostly handle reads. This spreads read load and adds redundancy if the leader goes down.
Multi-leader replication — multiple nodes can accept writes, which is more resilient but opens the door to write conflicts that need to be resolved somehow.

The concept that stuck with me most: replication isn't free. The moment you have copies of data, you have to decide how quickly those copies need to agree with each other. That's where I ran straight back into the CAP theorem from yesterday — replication is where "choose consistency or availability" actually shows up in a real design decision.

Sharding: Splitting Data Across Machines

If replication is about copying the same data across machines, sharding is about splitting different data across machines. Instead of one giant database holding everything, you partition data — often by a key like user ID or region — so no single machine has to hold or serve all of it.

A few things I noted:

Sharding key choice matters a lot. Pick a bad key (like something unevenly distributed) and you end up with "hot shards" — some machines overloaded while others sit idle.
Sharding solves a storage/throughput problem, but introduces new ones: queries that need data from multiple shards get more complex, and cross-shard transactions are painful.
This is usually a "last resort" scaling technique — you shard once vertical scaling and replication aren't enough anymore.

Replication + Sharding Together

In real large-scale systems, these aren't either/or — they're often combined. You shard data across multiple database clusters, and within each shard, you replicate for redundancy and read scaling. It was helpful to picture this as a grid: shards along one axis, replicas along the other.

What Clicked Today

The biggest realization: most of these decisions come back to the same question I hit yesterday — what are you willing to give up, and when?

Give up some consistency to get more availability
Give up simplicity to get more scale
Give up flexibility to get stronger guarantees

Database design isn't a checklist. It's a series of trade-off calls based on what the system actually needs to do.

Tomorrow

Next up: caching. Where caches fit in a system, cache invalidation strategies, and why "there are only two hard things in computer science: cache invalidation and naming things" is apparently a very real problem and not just a joke.

If you work with distributed databases day to day — what's a sharding or replication decision that bit you later on? I'd love to hear the war stories.

*This is part of a 30-day series on learning system design from scratch. Catch up on Day 1 if you missed it.*v

Day 1 of 30: Kicking Off My System Design Learning Journey published: false tags: systemdesign, beginners, learning, softwareengineering

Daniel Keya — Sun, 05 Jul 2026 13:37:40 +0000

Why I'm Doing This

I've been writing code professionally for a while now, but there's a gap in my knowledge that keeps showing up in interviews and in my own projects: system design. I can build a feature, ship an API, write clean code — but ask me to design something that needs to handle millions of users, and I start hand-waving.

So I'm giving myself 30 days to fix that. This is Day 1 of a series where I'll document what I learn, the mistakes I make, and the "aha" moments along the way. If you're on a similar journey, follow along — maybe we can learn together.

What Even Is System Design?

At its core, system design is about answering one question: how do you build software that works reliably at scale?

That means thinking about things like:

How does data move between a client and a server?
What happens when one server isn't enough?
How do you keep data consistent across multiple machines?
What breaks first when traffic spikes 100x?
How do you design for failure, not just for the happy path?

It's less about writing code and more about making trade-offs. Every decision in system design — cache vs. no cache, SQL vs. NoSQL, sync vs. async — comes with a cost. Today was about internalizing that mindset shift.

Topics I Covered Today

1. Client-Server Architecture

The absolute foundation. A client sends a request, a server processes it and sends back a response. Simple in theory, but I spent time really understanding the layers involved:

DNS resolution
Load balancers
Application servers
Databases

Mapping out a basic request lifecycle (browser → DNS → load balancer → server → database → back) made a lot of "why do we need X" questions click into place.

2. Vertical vs. Horizontal Scaling

Vertical scaling = throwing more resources (CPU, RAM) at a single machine. Simple, but has a ceiling.
Horizontal scaling = adding more machines. More complex (hello, distributed systems problems), but it's how you actually scale to millions of users.

Key takeaway: almost every large-scale system eventually needs to scale horizontally, and that decision ripples into everything else — session management, data consistency, caching strategy.

3. Latency vs. Throughput

Two terms I always mixed up:

Latency — how long a single request takes
Throughput — how many requests you can handle per unit of time

You can optimize for one at the expense of the other. Understanding which one matters more for a given system (e.g., a stock trading platform cares deeply about latency; a batch data pipeline cares more about throughput) is a design decision in itself.

4. The CAP Theorem (just the surface)

I only scratched the surface here, but the core idea stuck: in a distributed system, you can't have perfect Consistency, Availability, and Partition tolerance all at once. Since network partitions are a fact of life, real systems have to choose between prioritizing consistency or availability when a partition happens.

I know I'll be coming back to this one in more depth later in the series.

My Study Approach for These 30 Days

To keep this from turning into passive video-watching, I'm structuring each day like this:

Learn one core concept (30–45 minutes of reading/videos)
Sketch it out — diagrams, not just notes. System design is visual.
Explain it simply — if I can't explain a concept in plain English, I don't actually understand it yet
Write it down — hence this series

What's Next

Tomorrow I'm diving into databases: SQL vs. NoSQL, when to use each, and how replication and sharding actually work under the hood.

If you've done a deep dive into system design before, I'd love to hear:

What tripped you up early on?
Any resources you'd recommend?
Anything you wish someone had told you on day 1?

Drop a comment below. See you on Day 2.

This is part of a 30-day series on learning system design from scratch. Follow along for the rest of the journey.

Why I Fell in Love with Go — And Why You Should Give It a Chance

Daniel Keya — Thu, 04 Jun 2026 14:16:50 +0000

Tags: go, golang, beginners, programming

If you told me two years ago that I'd be writing a love letter to a programming language, I'd have laughed. But here I am.

Go (or Golang) changed the way I think about software development. And if you haven't tried it yet — or tried it and gave up — I want to make the case for why 2024 is the perfect year to give it a real shot.

What Even Is Go?

Go is an open-source programming language designed at Google by Robert Griesemer, Rob Pike, and Ken Thompson. It was released in 2009, but it has exploded in popularity over the last few years, powering tools you probably use every day: Docker, Kubernetes, Terraform, Prometheus, and more.

It sits in a sweet spot: it has the performance of a compiled language like C, but it feels almost as productive as Python or JavaScript. That's a rare combination.

The Things That Will Surprise You

1. The Simplicity Is the Point

Go has around 25 keywords. Compare that to Java (~50) or C++ (~90+). The language designers made a deliberate choice: less is more.

package main

import "fmt"

func main() {
    fmt.Println("Hello, Gopher! 🐹")
}

That's it. No classes. No inheritance. No decorators. Just clean, readable code. When you read someone else's Go code, you can actually understand it.

2. Concurrency Is a First-Class Citizen

One of Go's killer features is goroutines — lightweight threads that let you run things concurrently without the headaches of traditional threading.

package main

import (
    "fmt"
    "time"
)

func sayHello(name string) {
    time.Sleep(100 * time.Millisecond)
    fmt.Printf("Hello, %s!\n", name)
}

func main() {
    go sayHello("Alice")
    go sayHello("Bob")
    go sayHello("Charlie")

    time.Sleep(500 * time.Millisecond)
}

Launching a goroutine costs just a few kilobytes of memory. You can run hundreds of thousands of them. This makes Go exceptional for building APIs, microservices, and anything that handles lots of simultaneous connections.

3. The Tooling Is Incredible

Go ships with everything you need baked in:

go fmt — formats your code automatically (no more arguments about tabs vs spaces)
go test — runs your tests
go build — compiles to a single binary
go vet — catches common mistakes
go mod — manages dependencies

No decision fatigue. No webpack configs. No 47 different linting tools to choose from. You just... write code.

4. It Compiles to a Single Binary

When you build a Go application, you get one binary file. No runtime to install. No dependencies to bundle. You can copy that file to any Linux server and it will just run.

GOOS=linux GOARCH=amd64 go build -o myapp .

For DevOps and deployment, this is a game-changer.

A Real Example: Building a Simple HTTP Server

Here's a fully working HTTP server in Go. No frameworks. No npm install. Just Go's standard library:

package main

import (
    "fmt"
    "net/http"
)

func helloHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Welcome to Go! You're going to love it here. 🐹")
}

func main() {
    http.HandleFunc("/", helloHandler)
    fmt.Println("Server running on http://localhost:8080")
    http.ListenAndServe(":8080", nil)
}

Run it with go run main.go. That's a production-grade HTTP server in under 15 lines.

"But Go Doesn't Have Generics…"

It does now! Go 1.18 (released in 2022) introduced generics, one of the most requested features in the language's history. The Go team took their time to get it right, and the result is a clean, practical implementation:

func Map[T, U any](slice []T, fn func(T) U) []U {
    result := make([]U, len(slice))
    for i, v := range slice {
        result[i] = fn(v)
    }
    return result
}

The language keeps getting better while staying true to its philosophy of simplicity.

A Word of Encouragement 💪

Learning a new programming language can feel overwhelming. You're going to write weird code at first. You're going to fight the compiler. You're going to wonder why there are no classes and feel slightly lost.

That's completely normal. That's part of the process.

Here's what I want you to know:

The Go community is one of the most welcoming in tech. The error messages are actually helpful. The documentation at pkg.go.dev is outstanding. And the moment things click — the moment you write a concurrent program that handles 10,000 requests per second on a tiny server — it's deeply satisfying.

You don't need to be a senior engineer to learn Go. You don't need a computer science degree. If you can write a for loop in any language, you can start learning Go today.

Where to Start

Here are the best free resources to get going (pun intended):

A Tour of Go — The official interactive tutorial. Do this first.
Go by Example — Hands-on examples for every feature.
The Go Playground — Write and run Go in your browser, no install needed.
Effective Go — Once you know the basics, this will make you write good Go.

Final Thoughts

Go won't solve every problem. It's not the best choice for machine learning, desktop apps, or scripting. But for backend services, CLIs, DevOps tooling, and APIs, it is hard to beat.

If you're a developer looking to add a powerful, pragmatic language to your toolkit — one that will make you more productive and more employable — Go deserves a serious look.

Start small. Build a CLI. Write a small REST API. Deploy it as a single binary and feel the magic.

The Gopher community is waiting for you. 🐹

Did this post inspire you to try Go? Drop a comment below — I'd love to hear what you're building. And if you're already a Gopher, what was the moment Go finally clicked for you?

If you found this helpful, consider following me for more posts on Go, backend development, and software craftsmanship.

Building My First React Component with TypeScript: A Beginner's Breakdown

Daniel Keya — Tue, 02 Jun 2026 21:53:12 +0000

So I just started learning React with TypeScript, and I want to share what I built and — more importantly — what I actually learned from it. If you're also new to this stack, this one's for you.

Here's the component I wrote:

import { useState } from "react";
import { Fragment } from "react/jsx-runtime";

interface Props {
  items: string[];
  heading: string;
}

export default function ListGroup({ items, heading }: Props) {
  const [selectdIndex, setSelectedIndex] = useState(-1);
  return (
    <Fragment>
      <h1>{heading}</h1>
      {items.length === 0 && <p>No item found</p>}
      <ul className="list-group">
        {items.map((item, index) => (
          <li
            className={
              selectdIndex === index
                ? "list-group-item active"
                : "list-group-item"
            }
            key={item}
            onClick={() => {
              setSelectedIndex(index);
            }}
          >
            {item}
          </li>
        ))}
      </ul>
    </Fragment>
  );
}

It's a ListGroup component — a clickable list that highlights whichever item you select. Simple, but packed with fundamentals. Let me walk you through what I learned.

1. TypeScript Interfaces for Props

interface Props {
  items: string[];
  heading: string;
}

In plain React (JavaScript), you can pass anything as props and React won't complain — until something breaks at runtime. TypeScript fixes this by letting you define exactly what a component expects.

Here, I'm saying: "This component must receive an array of strings (items) and a string (heading). Nothing else, nothing less."

The component signature then uses destructuring to pull those props out cleanly:

function ListGroup({ items, heading }: Props)

This is cleaner than writing props.items and props.heading everywhere.

2. useState — Tracking Which Item Is Selected

const [selectdIndex, setSelectedIndex] = useState(-1);

useState is React's way of giving a component memory. Without it, clicking an item would do nothing visible — React wouldn't know anything changed.

-1 is the initial value, meaning nothing is selected yet
selectdIndex holds the current state
setSelectedIndex is the function we call to update it

💡 Quick note: There's a typo here — selectdIndex should be selectedIndex. These things happen when you're learning! TypeScript won't catch variable name typos, only type mismatches.

3. Fragment — Because JSX Needs One Root Element

return (
  <Fragment>
    <h1>{heading}</h1>
    ...
  </Fragment>
);

JSX has a rule: every component must return a single root element. But wrapping everything in an extra <div> just to satisfy that rule can mess up your CSS layout.

Fragment is the solution — it's an invisible wrapper that groups elements without adding anything to the DOM. You can also write it as the shorthand <>...</>.

4. Conditional Rendering

{items.length === 0 && <p>No item found</p>}

This is a neat React pattern. If items.length === 0 is true, React renders the <p> tag. If it's false, React renders nothing. It's the JSX equivalent of an if statement, inline.

5. Rendering a List with `.map()`

{items.map((item, index) => (
  <li key={item}>
    {item}
  </li>
))}

To render a list dynamically in React, you use .map() to transform each array item into a JSX element.

The key prop is important — React uses it internally to track which items have changed, been added, or removed. Without it, you'll get a console warning and potentially buggy re-renders.

6. Dynamic CSS Classes

className={
  selectdIndex === index
    ? "list-group-item active"
    : "list-group-item"
}

This is a ternary operator used to conditionally apply a CSS class. If the current item's index matches selectdIndex, it gets the active class (which highlights it in Bootstrap). Otherwise, it just gets the base class.

It's a clean way to reflect state visually.

7. Handling Click Events

onClick={() => {
  setSelectedIndex(index);
}}

When a list item is clicked, we call setSelectedIndex(index) with the clicked item's index. React then re-renders the component with the new state, and the correct item gets the active class.

Putting It All Together

Here's the full picture of what happens when you use this component:

A parent component passes in an items array and a heading string
The component renders the heading, an empty-state message (if needed), and the list
When you click an item, setSelectedIndex updates the state
React re-renders, and the clicked item gets highlighted

What I'd Improve Next

Fix the typo: selectdIndex → selectedIndex
Use <>...</> shorthand instead of <Fragment> (cleaner to read)
Emit the selected item to the parent via an onSelectItem callback prop — right now the selection is trapped inside the component

Final Thoughts

This small component taught me a lot: TypeScript interfaces, state management, conditional rendering, list rendering, and event handling — all in ~30 lines of code. React with TypeScript felt intimidating at first, but once you see how the pieces fit together, it starts to click.

If you're also just starting out, I hope this breakdown helped. Let me know what you're building in the comments!

Tags: #react #typescript #beginners #webdev

Designing TikTok from Scratch — A System Design Deep Dive

Daniel Keya — Mon, 25 May 2026 22:24:05 +0000

Who is this for? Mid-to-senior engineers preparing for system design interviews, or anyone curious how a short-video platform at billion-user scale actually works under the hood.

Scale We're Designing For

Metric	Number
Monthly active users	1B+
Videos uploaded per day	~34 million
Target feed latency (P99)	~167ms
Peak egress bandwidth	~26 Tbps

1. Requirements

Before drawing a single box, nail down what the system must do — and what it doesn't need to do perfectly on day one.

Functional requirements:

Upload and transcode short videos
Serve a personalized "For You" feed
Like, comment, share, follow
Search videos and creators
Live streaming

Non-functional requirements:

High availability (99.99% uptime)
Sub-200ms feed latency
Horizontal scalability
Global CDN video delivery
Strong eventual consistency

2. High-Level Architecture

The system splits into four major domains: ingestion (upload pipeline), serving (read path), recommendation (ML feed), and social graph.

┌─────────────────────────────────────────────────┐
│              Mobile / Web Clients                │
└─────────────────────┬───────────────────────────┘
                      │
┌─────────────────────▼───────────────────────────┐
│         Global CDN / Edge PoPs                   │
│   Video delivery, static assets, geo-routing    │
└─────────────────────┬───────────────────────────┘
                      │
┌─────────────────────▼───────────────────────────┐
│       API Gateway + Load Balancer                │
│   Auth, rate limiting, routing, TLS termination │
└────────┬────────────┴────────────────┬──────────┘
         │                             │
   ┌─────▼──────┐  ┌──────────────┐  ┌▼────────────────┐
   │  Upload    │  │ Feed Service │  │  Social Graph   │
   │  Service   │  │(pre-compute  │  │    Service      │
   │            │  │ + real-time) │  │                 │
   └─────┬──────┘  └──────┬───────┘  └┬────────────────┘
         │                │            │
   ┌─────▼──────┐  ┌──────▼───────┐  ┌▼────────────────┐
   │ Transcode  │  │Recommendation│  │  Notification   │
   │  Workers   │  │   Engine     │  │    Service      │
   └─────┬──────┘  └──────┬───────┘  └┬────────────────┘
         │                │            │
   ┌─────▼──────┐  ┌──────▼───────┐  ┌▼────────────────┐
   │  Object    │  │ Feature Store│  │  Search Service │
   │  Storage   │  │(Redis+Cassie)│  │ (Elasticsearch) │
   └─────┬──────┘  └──────┬───────┘  └┬────────────────┘
         │                │            │
┌────────▼────────────────▼────────────▼──────────────┐
│              Async Message Bus (Kafka)               │
└──────────┬──────────────┬──────────────┬────────────┘
           │              │              │
    ┌──────▼─────┐ ┌──────▼────┐ ┌──────▼──────┐
    │MySQL/Vitess│ │   Redis   │ │  Cassandra  │
    │(user data, │ │ (counters,│ │ (timelines, │
    │ metadata)  │ │  cache)   │ │  history)   │
    └────────────┘ └───────────┘ └─────────────┘

All services communicate asynchronously via Kafka for non-critical paths.

3. Key Components Explained

CDN + Edge PoPs

TikTok's secret weapon. ~70% of video traffic is served directly from edge nodes in 150+ cities, bypassing origin entirely. It uses Anycast routing to send users to the nearest PoP. Manifest files (playlist URLs) are invalidated within seconds of a video going viral.

Upload Pipeline

Chunked multi-part upload (5 MB chunks) tolerates flaky mobile connections. Workers dedup via SHA-256 before writing. Transcode jobs run on GPU fleets — outputs include 360p, 720p, 1080p, and HEVC variants. Thumbnails and stills are extracted for ML feature generation.

Recommendation Engine

A two-tower neural network:

Tower 1 — encodes user state (watch history, device, time of day, location)
Tower 2 — encodes video features (visual embeddings, audio, caption text)

Dot product gives a relevance score. The model runs online for top-k retrieval, then a ranker applies real-time signals (trending, friend activity) before the feed is assembled.

Feed Assembly (Pre-compute + Real-time Merge)

This is where TikTok differs from Twitter/Instagram:

Celebrity/high-follow accounts — fan-out on write (posts pushed to follower inboxes eagerly)
Regular accounts — fan-out on read (merged at request time)

The feed service merges both lists, injects ML-recommended videos, and applies diversity rules to avoid repetition. Final feed is cached in Redis with a 300s TTL.

Kafka Message Bus

All write events (upload complete, like, follow, watch-complete) are published to Kafka topics. Downstream consumers include:

Analytics pipeline
Notification fan-out
ML feature store updater
Search indexer

Topics are partitioned by user_id for ordered processing per user. This decouples services and allows independent scaling.

Database Strategy

Store	Use Case	Why
MySQL / Vitess	User profiles, video metadata, social graph	ACID, sharded by `user_id`
Redis Cluster	Counters (likes, views), session tokens, feed cache	Sub-millisecond reads
Cassandra	Watch history, timelines, notification logs	Wide-row reads, high write throughput

4. Key Design Trade-offs

Fan-out on Write vs Read

The classic dilemma in social feed systems. TikTok uses a hybrid approach (the "celebrity problem" split):

Fan-out on write (for accounts with millions of followers):

Read path is O(1) — just read the inbox
Fast feed assembly at serving time
Massive write amplification when a celebrity posts

Fan-out on read (for regular users):

No write amplification on post
Storage-efficient
Slower feed assembly if following thousands of accounts

Eventual vs Strong Consistency

Like/view counts can lag by a few seconds — nobody notices. But user authentication tokens and billing events require strong consistency. TikTok segments these into separate storage tiers with different consistency guarantees, accepting complexity for throughput on hot paths.

Push vs Pull for Notifications

Likes and comments use WebSocket push for real-time delivery. Less critical notifications (weekly summaries, suggested follows) use a pull-based batch pipeline that runs every few hours — no need to maintain a persistent connection for a weekly digest email.

5. Back-of-Envelope Estimates

Assumptions: 1B MAU, 500M DAU, avg user watches 45 min/day, avg video = 30 sec ~= 8 MB (720p). 34M uploads/day ~= 400 uploads/sec peak.

Storage:

34M uploads/day x 8 MB x 3 resolutions = ~816 TB/day of new video
With 3x replication over 5 years = ~4.4 EB total raw storage

Feed reads:

500M DAU x 20 feed refreshes/day / 86,400 sec = ~115,000 feed reads/sec
With 95% Redis cache hit rate -> recommendation backend sees ~5,750 rps

Bandwidth:

500M users x 45 min x 2 Mbps (720p) / 86,400 = ~26 Tbps peak egress

This is why TikTok operates its own backbone in many regions and has deep-peering agreements with major ISPs.

6. What Makes TikTok's Architecture Special?

Most social platforms optimize for social graph traversal — show me what people I follow posted. TikTok inverted this: the algorithm is the product. The architecture is built around a recommendation pipeline that must be both blazing-fast and constantly learning from watch signals.

Three things stand out:

Aggressive edge caching — they push video delivery as close to the user as physically possible. The CDN is not a performance optimization; it is the entire delivery strategy.
Real-time ML feedback loops — a video's trajectory is decided in the first 30 minutes based on completion rate signals. A new creator can go viral without any followers.
Microservice isolation — upload, serving, recommendation, and social graph are independently deployable and scalable, preventing any single bottleneck from cascading.

Interview Tips

If you're using this for a system design interview:

Start with requirements — always clarify scale before designing anything
Estimate first — back-of-envelope math shows you understand the constraints
Sketch the high-level diagram — then dive into the component your interviewer cares about
Talk through trade-offs — interviewers want reasoning, not a list of technologies
Bottleneck hunt — proactively identify where the system will break and how you'd fix it

Found this useful? Follow for more system design deep dives — next up: designing YouTube's upload pipeline at scale.

Two tiny functions that make your async code production-ready: `retry` and `timeout`

Daniel Keya — Sun, 24 May 2026 00:01:00 +0000

Every async function you write assumes the network cooperates, the server responds, and the database doesn't hiccup. In production, none of those assumptions hold forever.

Here are two higher-order functions — each under 15 lines — that make any async function resilient without touching its internals.

The problem

You have an async function. Maybe it calls an API, queries a database, or reads a file over the network.

async function fetchUserData(userId) {
    const response = await fetch(`/api/users/${userId}`);
    return response.json();
}

Two things will go wrong eventually:

It will fail intermittently and you'll want to retry it
It will hang indefinitely and you'll want to give up after a deadline

You could wrap every function in retry logic and timeout logic inline. Or you could write it once, properly, and wrap any function you want.

`retry` — automatic reattempts on failure

export function retry(count, callback) {
  return async function (...args) {
    let attempts = 0;
    let lastError;

    while (attempts <= count) {
      try {
        return await callback(...args);
      } catch (err) {
        lastError = err;
        attempts++;
      }
    }

    throw lastError;
  };
}

How it works

retry is a higher-order function — it takes a function and returns a new function with retry behaviour baked in. The original function is untouched.

The while (attempts <= count) condition is deliberate. If count is 3, the loop runs when attempts is 0, 1, 2, 3 — that's 4 total executions: one initial attempt plus three retries. This matches the natural language meaning of "retry 3 times".

On success, return await callback(...args) exits immediately — no more iterations. On failure, the error is stored in lastError and attempts increments. Once the loop exhausts all attempts, the last error is rethrown — not a generic new Error('Max retries reached'), but the actual error the callback produced. Your callers get a meaningful error message, not a wrapper.

Usage

const resilientFetch = retry(3, fetchUserData);

// Works exactly like fetchUserData, but retries up to 3 times on failure
const user = await resilientFetch('user_123');

Why `await` inside `try` matters

try {
    return await callback(...args); // ✓ catches rejected promises
} catch (err) { ... }

Without await, a rejected promise escapes the try/catch entirely:

try {
    return callback(...args); // ✗ returns a pending promise — catch never fires
} catch (err) { ... }

await unwraps the promise inside the try block, so rejections are catchable. This is one of the most common async/await mistakes and retry only works correctly because it gets this right.

`timeout` — give up after a deadline

export function timeout(delay, callback) {
  return async function (...args) {
    const timer = new Promise((_, reject) =>
      setTimeout(() => reject(new Error('timeout')), delay)
    );

    return Promise.race([callback(...args), timer]);
  };
}

How it works

Promise.race resolves or rejects with whichever promise settles first. This function creates a race between two competitors:

callback(...args) — the actual work
timer — a promise that rejects after delay milliseconds

If the callback finishes in time, its value wins and timer becomes irrelevant. If delay milliseconds pass first, timer rejects with Error('timeout') and the callback's eventual result is ignored.

Notice the timer promise is constructed with (_, reject) — it never resolves, only rejects. This ensures the timer can never accidentally win the race with a successful value; it can only interrupt with a failure.

Usage

const limitedFetch = timeout(5000, fetchUserData);

try {
    const user = await limitedFetch('user_123');
} catch (e) {
    if (e.message === 'timeout') {
        console.error('Request took too long');
    }
}

Combining them

Both functions return async functions with the same signature as their input — which means they compose cleanly.

// Retry up to 3 times, but abandon any single attempt after 5 seconds
const resilientFetch = retry(3, timeout(5000, fetchUserData));

await resilientFetch('user_123');

Here's what happens on each attempt:

timeout(5000, fetchUserData) races the fetch against a 5-second timer
If it times out, timeout rejects with Error('timeout')
retry catches that rejection, increments attempts, and tries again
After 3 retries all fail, retry rethrows the last error

Four attempts, each with a 5-second ceiling, maximum 20 seconds total. All from two composable functions and one line of setup.

What makes these worth keeping

They don't modify the original function. fetchUserData is unchanged. You can use it with or without retry/timeout anywhere else.

They forward arguments transparently. ...args passes everything through — the wrapped function behaves identically to the original from the caller's perspective.

They preserve the error. retry rethrows lastError, not a new generic error. timeout rejects with a named Error('timeout') you can check by message. Callers always know what actually went wrong.

They compose. Because both return async functions with matching signatures, you can layer them in any order and they work together without knowing about each other.

The pattern

Both functions follow the same structure:

higherOrderFn(config, callback) {
    return async function (...args) {
        // enhanced behaviour around callback(...args)
    }
}

This is the decorator pattern applied to async functions. You write the enhancement once, and apply it to any async function that needs it — no inheritance, no classes, no modification of the original. Just functions wrapping functions.

It's a small pattern. It shows up everywhere once you start looking for it.

When async functions tell stories: dissecting a real-world JavaScript code review

Daniel Keya — Sat, 23 May 2026 23:55:39 +0000

You're reviewing a teammate's pull request. The function looks fine at first glance — it's async, it has a try/catch, it returns strings. Then you look closer and realise it has a bug that will silently swallow errors and return the wrong thing in production.

Let's walk through it.

The code

async function isWinner(country) {
    try {
        country = await db.getWinner(country);
        if (country === Error('Country Not Found')) {
            return `${country.name} never was a winner`;
        }
        if (country.continent !== 'Europe') {
            return `${country.name} is not what we are looking for because of the continent`;
        }
        let results = await db.getResults(country.id);
        if (results === Error('Results Not Found')) {
            return `${country.name} never was a winner`;
        }
        if (results.length < 3) {
            return `${country.name} is not what we are looking for because of the number of times it was champion`;
        }
        return (
            `${country.name} won the FIFA World Cup in ` +
            results.map((result) => result.year).join(', ') +
            ' winning by ' +
            results.map((result) => result.score).join(', ')
        );
    } catch (e) {
        if (e.message === 'Country Not Found') {
            return `${country} never was a winner`;
        }
    }
}

This function queries a database for a country's FIFA World Cup wins. It checks if a country exists, if it's in Europe, if it won at least 3 times, and then formats the results.

Reasonable goal. Shaky execution.

Bug #1: comparing errors with `===`

if (country === Error('Country Not Found')) {

This will never be true.

Error('Country Not Found') creates a brand new Error object every time it's called. In JavaScript, objects are compared by reference, not by value. So country === Error('Country Not Found') is asking "is country the exact same object in memory as this new Error I just created?" — and the answer is always no.

const a = Error('Country Not Found');
const b = Error('Country Not Found');
console.log(a === b); // false — different objects

The same bug appears further down with results === Error('Results Not Found').

What was probably intended:

The database likely throws when a country isn't found, rather than returning an Error object. In that case, the catch block handles it. If the db genuinely returns an Error instance, the correct check is:

if (country instanceof Error) { ... }
// or
if (country?.message === 'Country Not Found') { ... }

Bug #2: overwriting the parameter

async function isWinner(country) {
    try {
        country = await db.getWinner(country); // ← overwrites the input

The function receives country as a string (e.g. "Brazil"), then immediately reassigns it to the database result object. This is why the catch block has to do this:

} catch (e) {
    if (e.message === 'Country Not Found') {
        return `${country} never was a winner`; // country is now an object, not a string
    }
}

If db.getWinner throws before assigning, country is still the original string — fine. But if it throws after a partial assignment, country could be anything. And if db.getResults throws, country is already the database object, so ${country} would render as [object Object] never was a winner.

Fix: use a separate variable.

async function isWinner(countryName) {
    const country = await db.getWinner(countryName);
    ...
}

Bug #3: the catch block returns `undefined`

} catch (e) {
    if (e.message === 'Country Not Found') {
        return `${country} never was a winner`;
    }
    // what happens here?
}

If the error is anything other than 'Country Not Found' — a network failure, a malformed response, a typo in the db call — the if condition is false and the catch block falls through without returning anything. The function returns undefined.

The caller gets back undefined with no indication that something went wrong. No rethrow, no fallback message, silent failure.

Fix: always handle the unexpected case.

} catch (e) {
    if (e.message === 'Country Not Found') {
        return `${countryName} never was a winner`;
    }
    throw e; // let unexpected errors propagate
}

A cleaner version

async function isWinner(countryName) {
    let country;
    try {
        country = await db.getWinner(countryName);
    } catch (e) {
        if (e.message === 'Country Not Found') {
            return `${countryName} never was a winner`;
        }
        throw e;
    }

    if (country.continent !== 'Europe') {
        return `${country.name} is not what we are looking for because of the continent`;
    }

    let results;
    try {
        results = await db.getResults(country.id);
    } catch (e) {
        if (e.message === 'Results Not Found') {
            return `${country.name} never was a winner`;
        }
        throw e;
    }

    if (results.length < 3) {
        return `${country.name} is not what we are looking for because of the number of times it was champion`;
    }

    return (
        `${country.name} won the FIFA World Cup in ` +
        results.map((r) => r.year).join(', ') +
        ' winning by ' +
        results.map((r) => r.score).join(', ')
    );
}

Each async operation gets its own try/catch scoped to its own error. The parameter is never overwritten. Unexpected errors are rethrown rather than swallowed.

The three takeaways

1. Never compare Error objects with ===. Errors are objects — two errors with the same message are not the same object. Use instanceof Error or check .message on a caught error.

2. Don't reuse parameters as working variables. The moment you reassign a parameter, you lose the original value everywhere — including the catch block where you might need it most.

3. A catch block that doesn't rethrow is a promise to handle everything. If you only handle one specific error and silently drop the rest, you're hiding bugs. Either handle all cases or rethrow what you can't handle.

Code review isn't about finding someone to blame. It's about finding the bugs before users do. This one had three of them hiding in plain sight behind reasonable-looking syntax.

Tags: javascript async debugging codereview webdev

Shared-Key Cryptosystems in JavaScript: A Practical Guide

Daniel Keya — Thu, 21 May 2026 18:33:33 +0000

Cryptography sounds intimidating — but once you understand the core idea behind shared-key (symmetric) cryptosystems, you'll wonder why you ever found it mysterious. In this post, we'll break down what it is, how it works, and how to implement it practically in JavaScript using the Web Crypto API.

What Is a Shared-Key Cryptosystem?

A shared-key cryptosystem (also called a symmetric-key cryptosystem) is one where the same key is used to both encrypt and decrypt data. Think of it like a physical padlock — whoever has the key can lock and unlock it.

Plaintext → [ Encrypt with Key K ] → Ciphertext → [ Decrypt with Key K ] → Plaintext

This is in contrast to asymmetric cryptography (like RSA), which uses a public/private key pair. Symmetric encryption is:

Fast — ideal for large amounts of data
Efficient — lower computational overhead
⚠️ Key distribution problem — both parties must securely share the same key

Popular shared-key algorithms include:

AES (Advanced Encryption Standard) — the gold standard today
ChaCha20 — modern, fast, used in TLS 1.3
3DES — legacy, being phased out

The Key Exchange Problem

Here's the fundamental challenge: if Alice and Bob want to communicate secretly using a shared key, how do they exchange that key without Eve intercepting it?

Alice ──── "Here's our secret key!" ────→   Eve intercepts  ──→ Bob

This is solved in practice by:

Diffie-Hellman key exchange — mathematically derive a shared secret over a public channel
Asymmetric encryption — encrypt the symmetric key with a public key, then decrypt with a private key (hybrid encryption, used in TLS)

For this post, we'll focus on the encryption/decryption mechanics assuming the key is already securely shared.

Hands-On: AES-GCM in JavaScript

The Web Crypto API (window.crypto.subtle) is built into modern browsers and Node.js 18+. It gives us access to AES-GCM — AES in Galois/Counter Mode — which provides both encryption and authentication (it detects tampering).

Step 1: Generate a Shared Key

async function generateKey() {
  const key = await crypto.subtle.generateKey(
    {
      name: "AES-GCM",
      length: 256, // 256-bit key — strong!
    },
    true,          // extractable: allows export
    ["encrypt", "decrypt"]
  );
  return key;
}

const sharedKey = await generateKey();
console.log("Key generated:", sharedKey);

Step 2: Encrypt a Message

AES-GCM requires a random IV (Initialization Vector) for every encryption. The IV doesn't need to be secret — just unique per operation.

async function encrypt(key, plaintext) {
  const iv = crypto.getRandomValues(new Uint8Array(12)); // 96-bit IV for AES-GCM
  const encodedText = new TextEncoder().encode(plaintext);

  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv },
    key,
    encodedText
  );

  // Return both IV and ciphertext — the IV is needed for decryption
  return { iv, ciphertext };
}

const message = "Hello, Bob! This is our secret message. ";
const { iv, ciphertext } = await encrypt(sharedKey, message);
console.log("Encrypted:", ciphertext);

Why bundle the IV with the ciphertext?

The IV is required for decryption. It's not secret — it just must be unique. Sending it alongside the ciphertext is standard practice.

Step 3: Decrypt the Message

async function decrypt(key, iv, ciphertext) {
  const decryptedBuffer = await crypto.subtle.decrypt(
    { name: "AES-GCM", iv },
    key,
    ciphertext
  );

  return new TextDecoder().decode(decryptedBuffer);
}

const decryptedMessage = await decrypt(sharedKey, iv, ciphertext);
console.log("Decrypted:", decryptedMessage);
// → "Hello, Bob! This is our secret message. "

Exporting and Importing Keys

In real applications, you'll need to serialize the key — to send it over a wire, store it in a database, or share it between sessions.

// Export the key to raw bytes
async function exportKey(key) {
  const exported = await crypto.subtle.exportKey("raw", key);
  return new Uint8Array(exported);
}

// Import raw bytes back into a CryptoKey
async function importKey(rawKeyBytes) {
  return crypto.subtle.importKey(
    "raw",
    rawKeyBytes,
    { name: "AES-GCM", length: 256 },
    true,
    ["encrypt", "decrypt"]
  );
}

const rawKey = await exportKey(sharedKey);
console.log("Raw key bytes:", rawKey);

const importedKey = await importKey(rawKey);
const testDecrypt = await decrypt(importedKey, iv, ciphertext);
console.log("Decrypted with imported key:", testDecrypt);
// ✅ Still works!

Putting It All Together: A Complete Example

// ============================================================
// Shared-Key Cryptosystem Demo — AES-GCM with Web Crypto API
// ============================================================

const Crypto = {
  async generateKey() {
    return crypto.subtle.generateKey(
      { name: "AES-GCM", length: 256 },
      true,
      ["encrypt", "decrypt"]
    );
  },

  async encrypt(key, plaintext) {
    const iv = crypto.getRandomValues(new Uint8Array(12));
    const encoded = new TextEncoder().encode(plaintext);
    const ciphertext = await crypto.subtle.encrypt(
      { name: "AES-GCM", iv },
      key,
      encoded
    );
    return { iv, ciphertext };
  },

  async decrypt(key, iv, ciphertext) {
    const buffer = await crypto.subtle.decrypt(
      { name: "AES-GCM", iv },
      key,
      ciphertext
    );
    return new TextDecoder().decode(buffer);
  },
};

// --- Simulation ---
(async () => {
  // Alice and Bob agree on a shared key (assume secure exchange)
  const sharedKey = await Crypto.generateKey();

  // Alice encrypts
  const secret = "The treasure is buried under the old oak tree. 🌳";
  const { iv, ciphertext } = await Crypto.encrypt(sharedKey, secret);
  console.log("Alice sends encrypted message.");

  // Bob decrypts
  const revealed = await Crypto.decrypt(sharedKey, iv, ciphertext);
  console.log("Bob reads:", revealed);
})();

Security Considerations ⚠️

Before you ship anything crypto-related, keep these in mind:

Practice	Why It Matters
Never reuse an IV	Reusing an IV with the same key completely breaks AES-GCM security
Use AES-GCM over AES-CBC	GCM provides authentication; CBC does not (vulnerable to padding oracle attacks)
Don't roll your own crypto	Stick to well-audited APIs like Web Crypto
Key length: 256-bit	128-bit is technically secure, but 256-bit is the modern standard
Protect your keys	An encrypted message is only as safe as the key protecting it

When to Use Shared-Key vs. Asymmetric Cryptography

	Shared-Key (Symmetric)	Asymmetric
Speed	Very fast	Slow
Key management	Single shared secret	Public/private pair
Best for	Bulk data encryption	Key exchange, digital signatures
Examples	AES, ChaCha20	RSA, ECC

In practice, most systems use both: asymmetric crypto to securely exchange a symmetric key, then symmetric crypto for the actual data. This is exactly how TLS/HTTPS works.

Recap

Here's what we covered:

Shared-key cryptosystems use the same key to encrypt and decrypt
They're fast and efficient, ideal for bulk data
The Web Crypto API gives you production-grade AES-GCM in the browser and Node.js
Always use a random, unique IV per encryption
🔐 Never reuse IVs, and never build your own crypto primitives

Cryptography in JavaScript has never been more accessible — and with the Web Crypto API, you have no excuse to use weak homebrew solutions. Go build something secure!

Found this helpful? Drop a ❤️ or leave a comment below. Got questions about key exchange or asymmetric crypto? Let me know — that's a great follow-up post topic!

Go Backend Frameworks: Which One Should You Actually Use?

Daniel Keya — Thu, 21 May 2026 02:25:23 +0000

Go ships with one of the most capable standard libraries of any modern language. net/http alone can take you surprisingly far — but the ecosystem has grown a rich set of frameworks and routers that sit on top of it, each with a different philosophy.

In this post we'll walk through the five most popular options, compare them honestly, and land on a recommendation based on what you're actually building.

The Contenders

Framework	GitHub Stars	Philosophy
`net/http`	(stdlib)	Zero dependencies, full control
Gin	77k+	Fast, minimal, huge ecosystem
Echo	29k+	Clean API, great middleware
Fiber	33k+	Express.js-inspired, fastest benchmarks
Chi	18k+	Lightweight router, stdlib-compatible

1. `net/http` — The Standard Library

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello, World!")
    })
    http.ListenAndServe(":8080", nil)
}

Go's built-in HTTP package is more capable than most developers give it credit for. No install, no version conflicts, no breaking changes between releases — it ships with Go itself.

Best for:

Teams that know Go well and want zero dependencies
Long-lived projects where stability matters more than convenience
Microservices where keeping the binary small is a priority

Watch out for:

No built-in router with path parameters (/users/:id) — you'll write that yourself or pull in a package
Middleware chaining is manual and can get verbose
No built-in JSON binding or validation helpers

2. Gin — The Industry Standard

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()

    r.GET("/users/:id", func(c *gin.Context) {
        id := c.Param("id")
        c.JSON(200, gin.H{"id": id})
    })

    r.Run(":8080")
}

Gin is the most widely used Go web framework by a significant margin. It gives you path parameters, JSON binding, validation, middleware, and group routing out of the box — all with benchmark numbers that rival raw net/http.

Best for:

REST APIs where you want to move fast
Teams new to Go who want familiar patterns and good documentation
Projects where community support and third-party middleware matter

Watch out for:

Context is Gin's own *gin.Context, not the stdlib context.Context — some packages expect the latter
Middleware can grow tangled in large codebases if you're not deliberate about structure
The gin.H shorthand is convenient but easy to overuse at the cost of type safety

3. Echo — The Clean Alternative

package main

import (
    "net/http"
    "github.com/labstack/echo/v4"
)

func main() {
    e := echo.New()

    e.GET("/users/:id", func(c echo.Context) error {
        id := c.Param("id")
        return c.JSON(http.StatusOK, map[string]string{"id": id})
    })

    e.Start(":8080")
}

Echo and Gin are often compared head to head. Echo's API is slightly more consistent — handlers return an error, which is more idiomatic Go than Gin's c.JSON() pattern. The built-in middleware is well-designed and the docs are excellent.

Best for:

Teams who like Gin's speed but want a cleaner, more idiomatic API
Projects that need strong built-in middleware (CORS, JWT, rate limiting)
Developers who care about error handling being a first-class citizen

Watch out for:

Smaller community than Gin — fewer third-party plugins and Stack Overflow answers
Slightly steeper learning curve for beginners coming from other languages

4. Fiber — The Express.js Port

package main

import "github.com/gofiber/fiber/v2"

func main() {
    app := fiber.New()

    app.Get("/users/:id", func(c *fiber.Ctx) error {
        id := c.Params("id")
        return c.JSON(fiber.Map{"id": id})
    })

    app.Listen(":8080")
}

If you've built APIs in Node.js with Express, Fiber will feel immediately familiar. It mirrors Express's API almost exactly — same method names, same patterns, same philosophy. Under the hood it uses fasthttp instead of net/http, which is why its benchmarks sit at the top of most comparisons.

Best for:

Developers migrating from Node.js/Express who want a gentle transition
High-throughput services where raw performance is the primary concern
Projects that don't need to interop with the net/http ecosystem

Watch out for:

fasthttp is not compatible with net/http — packages that expect a standard http.Handler won't work
Less idiomatic Go — the API optimises for familiarity over correctness
Smaller ecosystem than Gin for middleware and plugins

5. Chi — The Minimal Router

package main

import (
    "fmt"
    "net/http"
    "github.com/go-chi/chi/v5"
)

func main() {
    r := chi.NewRouter()

    r.Get("/users/{id}", func(w http.ResponseWriter, r *http.Request) {
        id := chi.URLParam(r, "id")
        fmt.Fprintf(w, "User: %s", id)
    })

    http.ListenAndServe(":8080", r)
}

Chi is not a framework — it's a router. It sits directly on top of net/http and uses standard http.Handler and http.HandlerFunc interfaces throughout. You bring your own middleware, your own JSON helpers, your own everything. What you get is a clean, composable routing layer with no surprises.

Best for:

Teams that want routing structure without committing to a full framework
Projects that need full net/http compatibility
Developers who prefer assembling tools over adopting opinions

Watch out for:

You're responsible for wiring together everything Gin and Echo give you for free
More upfront setup — not ideal when you need to move fast

Head-to-Head Comparison

	net/http	Gin	Echo	Fiber	Chi
Performance	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Ease of use	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Community	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
stdlib compat	✅	⚠️	⚠️	❌	✅
Middleware	Manual	Built-in	Built-in	Built-in	Manual
Idiomatic Go	✅	⚠️	✅	⚠️	✅

My Pick

There is no single best answer — but here's how I actually choose:

→ Building a REST API and want to move fast? Use Gin. The ecosystem is massive, the docs are good, and you'll find answers to every problem you hit.

→ Want Gin's speed with cleaner, more idiomatic code? Use Echo. The error-return pattern is more Go-like and the built-in middleware is excellent.

→ Coming from Node.js/Express? Use Fiber to get productive immediately — then consider migrating to something more idiomatic once you're comfortable with Go.

→ Want full control with minimal dependencies? Use Chi for routing and bolt on exactly what you need.

→ Building something you'll maintain for years with a Go-fluent team? Use net/http directly. It'll outlast every framework on this list.

The Honest Truth

Most Go backend performance debates are irrelevant at the scale most of us actually operate at. Gin, Echo, and Fiber all handle tens of thousands of requests per second on modest hardware. The framework won't be your bottleneck — your database will.

Pick based on:

What your team already knows
How much you value idiomatic Go vs developer ergonomics
Whether you need net/http compatibility
How long you plan to maintain this

The best Go framework is the one your team can understand, extend, and debug at 2am without wanting to quit.

What's Your Pick?

Every Go developer has an opinion on this. Are you a Gin loyalist? A stdlib purist? Did Fiber win you over from Node.js?

Drop it in the comments — I'd love to know what you're running in production and why.

Written with ❤️ in Go

If you enjoyed this, feel free to check out more of my work on GitHub 👉 keyadaniel56 — always building something new in Go and beyond.

DEV Community: Daniel Keya

Day 5 of 30: Message Queues and Why Not Everything Needs an Instant Response

The Assumption I Didn't Know I Had

What a Message Queue Actually Does

Why This Matters for Scaling

Delivery Guarantees: The Part That Gets Complicated Fast

Queue vs. Pub/Sub

What Clicked Today

Tomorrow

title: Day 4 of 30: Load Balancing and the Single Point of Failure Problem

Why Load Balancers Exist

Load Balancing Algorithms

Layer 4 vs. Layer 7 Load Balancing

Health Checks: How the Load Balancer Knows What's Alive

The Load Balancer Becomes a Single Point of Failure

What Clicked Today

Tomorrow

Day 3 of 30: Caching, and Why Invalidation Really Is That Hard

Recap

Why Caching Exists

Where Caches Live

Caching Strategies

Cache Invalidation: The Actually Hard Part

Cache Stampede — A Failure Mode I Hadn't Considered

What Clicked Today

Tomorrow

Day 2 of 30: Databases, Replication, and Sharding published: false tags: systemdesign, beginners, learning, databases

Recap

SQL vs. NoSQL: Less "Which Is Better," More "Which Fits"

Replication: Copies for Reliability and Speed

Sharding: Splitting Data Across Machines

Replication + Sharding Together

What Clicked Today

Tomorrow

Day 1 of 30: Kicking Off My System Design Learning Journey published: false tags: systemdesign, beginners, learning, softwareengineering

Why I'm Doing This

What Even Is System Design?

Topics I Covered Today

1. Client-Server Architecture

2. Vertical vs. Horizontal Scaling

3. Latency vs. Throughput

4. The CAP Theorem (just the surface)

My Study Approach for These 30 Days

What's Next

Drop a comment below. See you on Day 2.

Why I Fell in Love with Go — And Why You Should Give It a Chance

What Even Is Go?

The Things That Will Surprise You

1. The Simplicity Is the Point

2. Concurrency Is a First-Class Citizen

3. The Tooling Is Incredible

4. It Compiles to a Single Binary

A Real Example: Building a Simple HTTP Server

"But Go Doesn't Have Generics…"

A Word of Encouragement 💪

Where to Start

Final Thoughts

Building My First React Component with TypeScript: A Beginner's Breakdown

1. TypeScript Interfaces for Props

2. useState — Tracking Which Item Is Selected

3. Fragment — Because JSX Needs One Root Element

4. Conditional Rendering

5. Rendering a List with .map()

6. Dynamic CSS Classes

7. Handling Click Events

Putting It All Together

What I'd Improve Next

Final Thoughts

Designing TikTok from Scratch — A System Design Deep Dive

Scale We're Designing For

1. Requirements

2. High-Level Architecture

3. Key Components Explained

CDN + Edge PoPs

Upload Pipeline

Recommendation Engine

Feed Assembly (Pre-compute + Real-time Merge)

Kafka Message Bus

Database Strategy

4. Key Design Trade-offs

5. Rendering a List with `.map()`

`retry` — automatic reattempts on failure

Why `await` inside `try` matters

`timeout` — give up after a deadline

Bug #1: comparing errors with `===`

Bug #3: the catch block returns `undefined`

1. `net/http` — The Standard Library