DEV Community: Daniel Keya

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.

Inverting an Object in JavaScript: Swap Keys and Values

Daniel Keya — Thu, 21 May 2026 02:04:28 +0000

Ever needed to look something up by value instead of by key? That's exactly what object inversion solves. In this short post we'll break down a clean invert utility that flips an object's keys and values — and explore where this pattern shows up in real code.

The Full Function

export function invert(obj) {
  const result = {};
  for (const [key, value] of Object.entries(obj)) {
    result[value] = key;
  }
  return result;
}

Usage:

console.log(invert({ a: "x", b: "y", c: "z" }));
// → { x: "a", y: "b", z: "c" }

Keys become values. Values become keys. Simple.

How It Works

Step 1 — Create an empty result object

const result = {};

We build the inverted object fresh rather than mutating the original. This keeps the function pure — no side effects, same input always gives same output.

Step 2 — Iterate with `Object.entries`

for (const [key, value] of Object.entries(obj)) {

Object.entries converts the object into an array of [key, value] pairs. Destructuring them directly in the for...of loop keeps the code clean — no pair[0] / pair[1] indexing needed.

For { a: "x", b: "y", c: "z" } this yields:

["a", "x"]
["b", "y"]
["c", "z"]

Step 3 — Assign with keys and values swapped

result[value] = key;

Each iteration assigns the original value as the new key, and the original key as the new value. That's the entire inversion logic — one line.

Step 4 — Return the result

return result;

The original object is untouched. A brand new inverted object is returned.

Dry Run: `{ a: "x", b: "y", c: "z" }`

Iteration	key	value	result after
1	`"a"`	`"x"`	`{ x: "a" }`
2	`"b"`	`"y"`	`{ x: "a", y: "b" }`
3	`"c"`	`"z"`	`{ x: "a", y: "b", z: "c" }`

Final output: { x: "a", y: "b", z: "c" }

Real-World Use Cases

This pattern comes up more often than you'd think:

Reverse lookup maps — you have a map of country codes to names and need to search by name:

const codes = { US: "United States", KE: "Kenya", DE: "Germany" };
const byName = invert(codes);
// { "United States": "US", "Kenya": "KE", "Germany": "DE" }

byName["Kenya"]; // → "KE"

Decoding encoded data — you encode values on the way out and decode on the way back:

const encode = { admin: "a1", user: "u2", guest: "g3" };
const decode = invert(encode);

decode["u2"]; // → "user"

Swapping label/value pairs in form selects — when an API returns the opposite shape from what your UI expects.

Edge Cases to Know

Duplicate values — last one wins

If two keys share the same value, the second assignment overwrites the first:

invert({ a: "x", b: "x" });
// → { x: "b" }   ← "a" is lost

This is not a bug in the function — it's a fundamental constraint. Object keys must be unique, so if your values aren't unique, inversion is lossy by definition.

Non-string values become strings

Object keys are always strings (or Symbols) in JavaScript. If your values are numbers or booleans, they get coerced when used as keys:

invert({ active: true, count: 42 });
// → { true: "active", 42: "count" }

The values true and 42 become the string keys "true" and "42". Usually harmless, but worth knowing.

Nested objects don't invert recursively

invert only works one level deep. If a value is itself an object, it becomes [object Object] as a key — almost certainly not what you want:

invert({ a: { nested: true } });
// → { "[object Object]": "a" }

For deep inversion you'd need a recursive approach with different logic.

A One-Liner Alternative

If you prefer a functional style without the explicit loop:

const invert = obj =>
  Object.fromEntries(Object.entries(obj).map(([k, v]) => [v, k]));

Same result — Object.entries unpacks, .map swaps each pair, Object.fromEntries repacks. The for...of version is easier to read at a glance; this one is more compact for quick use.

Complexity


Time	O(n) where n = number of keys
Space	O(n) for the new result object

Every key is visited once. A new object of equal size is created.

Wrapping Up

invert is one of those utility functions small enough to fit in a tweet but useful enough to reach for regularly. The pattern — Object.entries to unpack, swap, reassign — is the same one powering mapEntries, filterEntries, and most other object transformation helpers.

Keep it in your utility belt. You'll need it.

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

Building a Nutrition Calculator in JavaScript: filter, map, and reduce on Objects

Daniel Keya — Thu, 21 May 2026 01:59:28 +0000

JavaScript's Array.prototype.filter, map, and reduce are well-known — but what about running the same operations on plain objects? In this post we'll walk through a compact nutrition calculator that wraps those patterns into reusable object utilities, then uses them to power real food math.

The Data: A Nutrition Database

const nutritionDB = {
  tomato:  { calories: 18,  protein: 0.9,   carbs: 3.9,   sugar: 2.6, fiber: 1.2, fat: 0.2   },
  vinegar: { calories: 20,  protein: 0.04,  carbs: 0.6,   sugar: 0.4, fiber: 0,   fat: 0     },
  oil:     { calories: 48,  protein: 0,     carbs: 0,     sugar: 123, fiber: 0,   fat: 151   },
  onion:   { calories: 0,   protein: 1,     carbs: 9,     sugar: 0,   fiber: 0,   fat: 0     },
  garlic:  { calories: 149, protein: 6.4,   carbs: 33,    sugar: 1,   fiber: 2.1, fat: 0.5   },
  paprika: { calories: 282, protein: 14.14, carbs: 53.99, sugar: 1,   fiber: 0,   fat: 12.89 },
  sugar:   { calories: 387, protein: 0,     carbs: 100,   sugar: 100, fiber: 0,   fat: 0     },
  orange:  { calories: 49,  protein: 0.9,   carbs: 13,    sugar: 9,   fiber: 0.2, fat: 0.1   },
};

Each key is a food name. Each value holds nutrients per 100g. A cart will represent how many grams of each item the user is using — and we'll scale everything from there.

The Three Object Utility Functions

Before the food logic, three tiny helpers are defined that mirror array methods but work on objects.

`filterEntries` — like `Array.filter` for objects

function filterEntries(object, callback) {
  return Object.fromEntries(
    Object.entries(object).filter(callback)
  );
}

Object.entries converts { a: 1, b: 2 } into [["a", 1], ["b", 2]]. After filtering, Object.fromEntries converts it back. The callback receives each [key, value] pair.

`mapEntries` — like `Array.map` for objects

function mapEntries(object, callback) {
  return Object.fromEntries(
    Object.entries(object).map(callback)
  );
}

Same pattern — entries go out as an array, get transformed by the callback, come back as an object. The callback must return a [key, value] pair.

`reduceEntries` — like `Array.reduce` for objects

function reduceEntries(object, callback, initialValue) {
  return Object.entries(object).reduce(callback, initialValue);
}

This one doesn't need Object.fromEntries at the end because reduce can return anything — a number, a string, an array, another object.

Why This Pattern?

These three functions are thin wrappers, but they remove the repetitive boilerplate of writing Object.entries(...).map(...).fromEntries(...) every time. You end up with code that reads like intent, not plumbing.

The Nutrition Functions

Now the real logic, built on top of those utilities.

`totalCalories` — sum calories across a cart

function totalCalories(cart) {
  const total = reduceEntries(cart, (acc, [item, grams]) => {
    return acc + (nutritionDB[item].calories * grams) / 100;
  }, 0);
  return parseFloat(total.toFixed(1));
}

A cart looks like { tomato: 200, garlic: 10 } — ingredient names mapped to grams used.

For each item, it looks up calories per 100g from nutritionDB, scales it to the actual gram amount (* grams / 100), and accumulates the total. toFixed(1) cleans up floating-point noise.

Example:

const cart = { tomato: 200, garlic: 10 };
totalCalories(cart);
// tomato: (18 * 200) / 100 = 36 kcal
// garlic: (149 * 10) / 100 = 14.9 kcal
// Total: 50.9

`lowCarbs` — filter out high-carb items

function lowCarbs(cart) {
  return filterEntries(cart, ([item, grams]) => {
    return (nutritionDB[item].carbs * grams) / 100 < 50;
  });
}

Returns a new cart object containing only items whose total carb contribution is under 50g. Useful for dietary filtering — keep only what fits a low-carb budget.

Example:

const cart = { tomato: 200, sugar: 100, orange: 150 };
lowCarbs(cart);

// tomato:  (3.9  * 200) / 100 = 7.8g  ✅ kept
// sugar:   (100  * 100) / 100 = 100g  ❌ filtered out
// orange:  (13   * 150) / 100 = 19.5g ✅ kept

// Result: { tomato: 200, orange: 150 }

`decimalPlaces` — count decimal precision

function decimalPlaces(n) {
  const s = n.toString();
  const dot = s.indexOf('.');
  return dot === -1 ? 0 : s.length - dot - 1;
}

A small helper that counts how many decimal places a number has. It's used by cartTotal to match the precision of the source data.

Input	Output
`18`	`0`
`0.9`	`1`
`14.14`	`2`
`53.99`	`2`

`cartTotal` — scale all nutrients for every item

function cartTotal(cart) {
  return mapEntries(cart, ([item, grams]) => {
    const nutrition = nutritionDB[item];
    const scaled = mapEntries(nutrition, ([nutrient, per100g]) => {
      const raw = (per100g * grams) / 100;
      const precision = decimalPlaces(per100g) + 1;
      return [nutrient, parseFloat(raw.toFixed(precision))];
    });
    return [item, scaled];
  });
}

This is the most interesting function — it uses nested mapEntries calls.

The outer map iterates over every item in the cart. The inner map iterates over every nutrient for that item and scales it from per-100g to the actual gram amount used. The precision is dynamically matched to the source value (e.g. if the DB stores 14.14, the scaled value is rounded to 3 decimal places).

Example:

const cart = { garlic: 10 };
cartTotal(cart);

// garlic has 149 cal, 6.4g protein, 33g carbs, etc. per 100g
// Scaled to 10g:
// {
//   garlic: {
//     calories: 14.9,
//     protein:  0.64,
//     carbs:    3.3,
//     sugar:    0.1,
//     fiber:    0.21,
//     fat:      0.05
//   }
// }

Putting It All Together

const myCart = {
  tomato:  200,
  garlic:  10,
  onion:   80,
  paprika: 5,
  orange:  150,
  sugar:   20,
};

console.log("Total calories:", totalCalories(myCart));
// → 124.7

console.log("Low-carb items:", lowCarbs(myCart));
// → { tomato: 200, garlic: 10, onion: 80, paprika: 5 }

console.log("Full breakdown:", cartTotal(myCart));
// → each item with all nutrients scaled to actual grams

Key Patterns to Take Away

Pattern	Function used	What it demonstrates
Object → filter → Object	`filterEntries` + `lowCarbs`	Declarative filtering with `Object.entries` / `fromEntries`
Object → reduce → scalar	`reduceEntries` + `totalCalories`	Aggregating object values into a single number
Object → map → Object	`mapEntries` + `cartTotal`	Transforming every value while keeping the shape
Nested map	`cartTotal` (inner `mapEntries`)	Operating on nested objects without mutation
Dynamic precision	`decimalPlaces`	Matching output precision to input precision

Things to Watch Out For

Missing keys — if a cart contains an item not in nutritionDB, nutritionDB[item] returns undefined and the function throws. Add a guard if your cart data is user-supplied:

if (!nutritionDB[item]) return acc; // skip unknown items

Floating-point arithmetic — 0.1 + 0.2 === 0.30000000000000004 in JS. The toFixed calls throughout handle this, but always be explicit about rounding when displaying nutrition data.

Object key order — Object.entries follows insertion order for string keys in modern JS engines, but the spec only guarantees this for integer-like keys. For display purposes it's fine; don't rely on it for logic.

Wrapping Up

This codebase is a great example of how a few well-named utility functions — filterEntries, mapEntries, reduceEntries — can make object manipulation read as cleanly as array operations. The nutrition domain is just the context; the underlying patterns apply anywhere you're working with plain objects as data structures.

Next step: add a sortEntries utility and rank cart items by calorie density.

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

String Union in Go: Merging Two Strings Without Duplicates

Daniel Keya — Thu, 21 May 2026 01:52:51 +0000

The Full Function

func Union() {
    if len(os.Args) < 3 {
        os.Stdout.Write([]byte("\n"))
        return
    }

    s1 := os.Args[1]
    s2 := os.Args[2]

    result := ""
    seen := make(map[rune]bool)

    for _, char := range s1 {
        if !seen[char] {
            result += string(char)
            seen[char] = true
        }
    }

    for _, char := range s2 {
        if !seen[char] {
            result += string(char)
            seen[char] = true
        }
    }

    os.Stdout.Write([]byte(result + "\n"))
}

What Does It Do?

It takes two strings from the command line, walks through both of them in order, and builds a result string containing each character at most once — in the order it was first encountered.

Think of it as a set union on the characters of two strings.

For example:

"hello" ∪ "world" → "helowrd" — l and o already seen from s1, so skipped in s2
"abc" ∪ "bcd" → "abcd" — b and c already covered, only d is new

Algorithm Walkthrough

Step 1 — Validate arguments

if len(os.Args) < 3 {
    os.Stdout.Write([]byte("\n"))
    return
}

At least 3 arguments are needed: the binary name + 2 strings. Unlike the strict != 3 check, this uses < 3 — so extra arguments are silently ignored rather than rejected.

Step 2 — Set up the seen-set

result := ""
seen := make(map[rune]bool)

seen is a hash map that tracks which characters have already been added to result. Using rune as the key (instead of byte) means this handles full Unicode out of the box — emoji, accented characters, CJK glyphs, all work correctly.

Step 3 — Walk `s1`, add unseen characters

for _, char := range s1 {
    if !seen[char] {
        result += string(char)
        seen[char] = true
    }
}

range over a string in Go yields rune values — so multi-byte characters are handled as single units. Each character is checked against seen: if it's new, it's appended and marked.

Step 4 — Walk `s2`, add only new characters

for _, char := range s2 {
    if !seen[char] {
        result += string(char)
        seen[char] = true
    }
}

Same logic, but now seen already contains everything from s1. Only characters that didn't appear in s1 (or earlier in s2) get added.

Step 5 — Print the result

os.Stdout.Write([]byte(result + "\n"))

The deduplicated union string is written to stdout, followed by a newline.

Dry Run: `"hello"` ∪ `"world"`

Processing `s1 = "hello"`

char	seen before?	result after	seen map
h	❌	`"h"`	{h}
e	❌	`"he"`	{h,e}
l	❌	`"hel"`	{h,e,l}
l	✅	`"hel"`	{h,e,l}
o	❌	`"helo"`	{h,e,l,o}

Processing `s2 = "world"`

char	seen before?	result after	seen map
w	❌	`"helow"`	{h,e,l,o,w}
o	✅	`"helow"`	{h,e,l,o,w}
r	❌	`"helowr"`	{h,e,l,o,w,r}
l	✅	`"helowr"`	{h,e,l,o,w,r}
d	❌	`"helowrd"`	{h,e,l,o,w,r,d}

Output: helowrd

Complexity


Time	O(m + n) where m = len(s1), n = len(s2)
Space	O(k) where k = number of unique characters

Each character is visited exactly once. Map lookups and inserts are O(1) average. In practice, k is bounded by the size of the character set (e.g. 128 for ASCII, 1,114,112 for all Unicode) so space is effectively constant.

Edge Cases

Scenario	Behaviour
Fewer than 2 args	Writes `\n`, returns immediately
Both strings identical	Result equals the deduplicated version of either string
Empty `s1`	Result is the deduplicated version of `s2`
Empty `s2`	Result is the deduplicated version of `s1`
Both empty	Result is an empty string followed by `\n`
Unicode characters	Handled correctly — `range` yields `rune`, map key is `rune`

Running It

# basic union
go run main.go hello world
# Output: helowrd

# no overlap
go run main.go abc xyz
# Output: abcxyz

# full overlap
go run main.go abc abc
# Output: abc

# unicode
go run main.go "café" "face"
# Output: café

A Note on String Concatenation

Inside the loop, the function uses:

result += string(char)

This works fine for short strings, but in Go, strings are immutable — every += creates a new string allocation. For large inputs, prefer strings.Builder:

var sb strings.Builder

for _, char := range s1 {
    if !seen[char] {
        sb.WriteRune(char)
        seen[char] = true
    }
}
// repeat for s2...

result := sb.String()

strings.Builder grows a single underlying buffer, making it O(n) in both time and allocations instead of O(n²).

Refactored: Pure Function

Separating the union logic from CLI parsing makes it reusable and testable:

// StringUnion returns the union of characters from a and b,
// preserving first-seen order, with no duplicates.
func StringUnion(a, b string) string {
    var sb strings.Builder
    seen := make(map[rune]bool)

    for _, char := range a {
        if !seen[char] {
            sb.WriteRune(char)
            seen[char] = true
        }
    }

    for _, char := range b {
        if !seen[char] {
            sb.WriteRune(char)
            seen[char] = true
        }
    }

    return sb.String()
}

func Union() {
    if len(os.Args) < 3 {
        os.Stdout.Write([]byte("\n"))
        return
    }
    result := StringUnion(os.Args[1], os.Args[2])
    os.Stdout.Write([]byte(result + "\n"))
}

Wrapping Up

Union is a clean example of the seen-set pattern — one of the most reusable tools in string processing. A hash map tracking visited elements lets you deduplicate in a single linear pass, and using rune as the key gives you Unicode support for free.

The same pattern shows up in removing duplicates from slices, finding first non-repeating characters, and building character frequency counters.

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.

Subsequence Matching in Go: The Two-Pointer Scan

Daniel Keya — Thu, 21 May 2026 01:48:10 +0000

Have you ever wondered how tools like fzf, VS Code's command palette, or fuzzy finders work under the hood? The core logic is often a subsequence match — and it's surprisingly simple to implement.

In this post, we'll break down a compact Go function called WdMatch that does exactly this.

The Full Function

func WdMatch() {
    if len(os.Args) != 3 {
        os.Stdout.Write([]byte("\n"))
        return
    }

    s1 := os.Args[1] // pattern  (needle)
    s2 := os.Args[2] // haystack (text)

    i := 0

    for j := 0; j < len(s2) && i < len(s1); j++ {
        if s1[i] == s2[j] {
            i++
        }
    }

    if i == len(s1) {
        os.Stdout.Write([]byte(s1 + "\n"))
    }
}

What Does It Do?

It checks whether every character of s1 (the pattern) appears in order inside s2 (the text) — not necessarily contiguous. If they do, it prints the pattern. Otherwise, it prints nothing.

This is called a subsequence check.

For example:

"ace" is a subsequence of "abcde" ✅ — a, c, e all appear in order
"aec" is not a subsequence of "abcde" ❌ — e comes after c in the text, breaking the order

Algorithm Walkthrough

Step 1 — Validate arguments

if len(os.Args) != 3 {
    os.Stdout.Write([]byte("\n"))
    return
}

The program expects exactly 3 arguments: the binary name + 2 strings. If that's not the case, it writes a bare newline and exits cleanly — no panic.

Step 2 — Assign the two strings

s1 := os.Args[1] // pattern
s2 := os.Args[2] // text
i := 0

s1 is what we're searching for. s2 is where we search. i tracks how far we've matched into the pattern.

Step 3 — The two-pointer loop

for j := 0; j < len(s2) && i < len(s1); j++ {
    if s1[i] == s2[j] {
        i++
    }
}

This is the core. Two pointers move through the strings:

j always advances — it walks every character of s2
i only advances when s1[i] == s2[j] — a match is found

The loop has a dual exit condition: it stops when s2 is exhausted OR when the full pattern has been matched (early exit).

Step 4 — Check for a complete match

if i == len(s1) {
    os.Stdout.Write([]byte(s1 + "\n"))
}

After the loop, if i reached the end of s1, every character was found in the right order. Pattern is printed. Otherwise — silence.

Dry Run Examples

✅ Match: `"ace"` in `"abcde"`

j	s2[j]	s1[i]	Match?	i after
0	a	a	✅	1
1	b	c	❌	1
2	c	c	✅	2
3	d	e	❌	2
4	e	e	✅	3

i == len("ace") == 3 → prints ace

❌ No Match: `"aec"` in `"abcde"`

j	s2[j]	s1[i]	Match?	i after
0	a	a	✅	1
1	b	e	❌	1
2	c	e	❌	1
3	d	e	❌	1
4	e	e	✅	2

Loop ends. i == 2, but len("aec") == 3 → nothing printed.

Complexity


Time	O(n) where n = len(s2)
Space	O(1) — no allocations inside the loop

Each character in s2 is visited at most once. Only two integer pointers are maintained.

Edge Cases

Scenario	Behaviour
Wrong arg count	Writes `\n`, returns immediately
Empty pattern `""`	Always matches — `i == 0 == len(s1)` after loop
Empty text `""`	Loop never runs; only empty pattern matches
Pattern longer than text	Loop exits before `i` reaches `len(s1)` — no match
Multi-byte Unicode	Byte indexing `s1[i]` breaks on chars like `é`. Use `[]rune` instead

Running It

# match: prints "ace"
go run main.go ace abcde

# no match: prints nothing
go run main.go aec abcde

# wrong args: prints a bare newline
go run main.go ace

Refactored: Separate the Logic from the CLI

The original function mixes argument parsing with the matching logic. Splitting them makes the core algorithm independently testable:

// IsSubsequence returns true if every byte of pattern
// appears in text in the same order.
func IsSubsequence(pattern, text string) bool {
    i := 0
    for j := 0; j < len(text) && i < len(pattern); j++ {
        if pattern[i] == text[j] {
            i++
        }
    }
    return i == len(pattern)
}

func WdMatch() {
    if len(os.Args) != 3 {
        os.Stdout.Write([]byte("\n"))
        return
    }
    if IsSubsequence(os.Args[1], os.Args[2]) {
        os.Stdout.Write([]byte(os.Args[1] + "\n"))
    }
}

Now you can write unit tests directly against IsSubsequence without touching os.Args.

Unicode Support

The original uses byte indexing (s1[i], s2[j]), which works perfectly for ASCII but breaks on multi-byte Unicode characters like é, 中, or 🔥.

To support full Unicode, convert to rune slices:

func IsSubsequenceRune(pattern, text string) bool {
    p := []rune(pattern)
    t := []rune(text)
    i := 0
    for j := 0; j < len(t) && i < len(p); j++ {
        if p[i] == t[j] {
            i++
        }
    }
    return i == len(p)
}

Same logic — just operating on code points instead of bytes.

Wrapping Up

WdMatch is a clean, allocation-free implementation of subsequence matching in about 15 lines of Go. The two-pointer approach is the same pattern powering real-world fuzzy finders — linear in the length of the text, constant in space, and easy to reason about.

If you found this useful, the next step is applying it to a list of words and filtering only those that match a given pattern — which is exactly how command-palette search works.

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.

From Go to JavaScript: A Gopher's Honest First Impressions

Daniel Keya — Mon, 11 May 2026 12:05:22 +0000

I've been writing Go for a while now. I love its simplicity, its strictness, and the way it basically yells at you if you do something wrong. The compiler is your grumpy but reliable friend — opinionated, fast, and absolutely zero tolerance for unused variables.

So when I decided to start learning JavaScript, I thought: how hard can it be? It's just a scripting language.

Reader, I was humbled.

The First Culture Shock: No Types? No Problem? (Apparently)

Coming from Go, the first thing that hit me was the complete absence of static typing — at least in vanilla JS.

In Go, if I write:

var age int = 25
age = "twenty-five" // compiler screams at you immediately

The compiler stops you dead in your tracks. That's a feature I had come to love and depend on.

In JavaScript?

let age = 25;
age = "twenty-five"; // totally fine, have a great day
age = [1, 2, 3];     // sure, why not
age = null;          // living dangerously, I see

JavaScript just... lets you. No complaints. No errors. Just vibes.

At first this felt like chaos. But I'm slowly starting to see it differently — it's flexible in a way Go intentionally isn't. The tradeoff is just that you have to carry the discipline the compiler used to carry for you.

(Yes, I know TypeScript exists. One thing at a time.)

`var`, `let`, and `const` — Why Are There Three of You?

In Go, variable declaration is clean:

x := 10        // short declaration
var y int = 20 // explicit declaration

In JavaScript, I was introduced to three keywords and immediately had questions:

var name = "Alice";   // the old way (avoid this, apparently)
let age = 30;         // block-scoped, reassignable
const lang = "JS";    // block-scoped, can't reassign

The var one especially confused me — it's function-scoped, hoisted, and has caused enough bugs in JavaScript history that the community largely agrees you shouldn't use it anymore. It's still there, just... frowned upon.

Go doesn't have this kind of legacy baggage sitting in the language. JavaScript has decades of "we can't break the web" baked right in.

Functions Are Everywhere — And They're First-Class Citizens

This one actually excited me. In Go, functions are also first-class, but JavaScript takes it to another level.

// Regular function
function greet(name) {
  return `Hello, ${name}!`;
}

// Arrow function
const greet = (name) => `Hello, ${name}!`;

// Immediately Invoked Function Expression (IIFE)
(() => console.log("I run immediately!"))();

Arrow functions especially feel sleek. Template literals (the backtick strings with ${}) are also something I wish Go had — fmt.Sprintf works, but it's nowhere near as readable.

Asynchronous Programming: Goroutines vs Promises

This is where things got interesting.

In Go, concurrency is handled with goroutines and channels — it's explicit, structured, and elegant in its own way:

go func() {
    result := fetchData()
    ch <- result
}()

JavaScript is single-threaded but handles async operations through an event loop, Promises, and async/await:

async function loadUser() {
  try {
    const response = await fetch("https://api.example.com/user");
    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.error("Something went wrong:", error);
  }
}

Once async/await clicked for me, it felt surprisingly readable. But understanding why JavaScript works this way — the event loop, the call stack, the callback queue — required a mental model completely different from Go's concurrency primitives.

Error Handling: I Miss You, Go

Okay, I'll be honest. Go's error handling gets a lot of jokes:

result, err := doSomething()
if err != nil {
    return err
}

Yes, it's verbose. Yes, you write if err != nil approximately one million times. But it forces you to think about errors at every step.

JavaScript? You can forget errors exist until they explode at runtime:

const data = JSON.parse(userInput); // will throw if input is invalid

try/catch is there, but it's optional. Nothing enforces that you use it. Coming from Go, this feels like walking a tightrope without a net.

What I'm Actually Enjoying

Despite the culture shock, I won't pretend JavaScript hasn't been fun. Here's what genuinely surprised me:

The browser feedback loop is instant. Change something, refresh — it's there. Go's compile step, while fast, still exists.
The ecosystem is enormous. npm has a package for everything. Possibly too many things.
Destructuring and spread operators are delightful.

const { name, age } = user;
const newArray = [...arr1, ...arr2];

The community content is incredible. MDN Web Docs, freeCodeCamp, JavaScript.info — the learning resources are top-notch.

The Mindset Shift

I think the biggest adjustment isn't the syntax — it's the philosophy.

Go is opinionated. It tells you there is one right way to format code (gofmt), one sensible way to handle errors, one clear way to structure packages. That rigidity is a feature.

JavaScript is the opposite. There are five ways to do everything, three of them are considered bad practice, and the community is actively debating the other two. It's liberating and overwhelming in equal measure.

Where I Am Now

I'm still early in the journey. I've got the fundamentals down, I'm getting comfortable with the DOM, and I'm starting to peek at what React looks like. The goal is to eventually be comfortable building full-stack things — and understanding JS properly feels like the necessary foundation before anything else.

If you're a fellow backend developer making the leap into JavaScript land, my advice is simple: don't fight the language. It's not Go. It's not trying to be Go. Once you accept that, it gets a lot more fun.

Thanks for reading! If you've made a similar transition — from Go, Rust, Java, or anything else — I'd love to hear how it went for you. Drop a comment below 👇

Tags: javascript golang beginners webdev

From Beginner to Worker Pools: Mastering Golang Channels with Real Code Examples"

Daniel Keya — Tue, 17 Mar 2026 15:23:45 +0000

Go's concurrency model is one of its biggest selling points — and at the heart of it all are channels. Channels let goroutines communicate safely without shared memory, making concurrent code cleaner and easier to reason about.

In this post, we'll walk through the patterns in this open-source project that teaches Go channels from the ground up: starting with the basics, then moving into real-world patterns like worker pools, pipelines, and rate limiters.

What Are Go Channels?

A channel is a typed conduit through which you can send and receive values between goroutines.

ch := make(chan int)       // unbuffered channel
bch := make(chan int, 10)  // buffered channel (capacity 10)

Unbuffered: the sender blocks until the receiver is ready (synchronous).
Buffered: the sender only blocks when the buffer is full (asynchronous up to capacity).

Pattern 1 — Worker Pool (Fan-Out)

The worker pool is the most common real-world channel pattern. A single master goroutine generates tasks and sends them on a shared channel. Multiple worker goroutines compete to pick up tasks from that same channel — this is called fan-out.

How it works

Master ──► [task channel] ──► Worker 1
                          ──► Worker 2
                          ──► Worker 3
                               │
                               ▼
                        [results channel]
                               │
                               ▼
                           Collector

Code walkthrough

Task definition (task.go)

type Task struct {
    ID   int
    Data string
}

type Result struct {
    TaskID int
    Output string
}

Worker function

func worker(id int, tasks <-chan Task, results chan<- Result, wg *sync.WaitGroup) {
    defer wg.Done()
    for task := range tasks {
        // simulate work
        output := fmt.Sprintf("Worker %d processed task %d: %s", id, task.ID, task.Data)
        results <- Result{TaskID: task.ID, Output: output}
    }
}

Master (main.go)

func main() {
    const numWorkers = 3
    tasks := make(chan Task, 10)
    results := make(chan Result, 10)

    var wg sync.WaitGroup

    // Spin up workers
    for i := 1; i <= numWorkers; i++ {
        wg.Add(1)
        go worker(i, tasks, results, &wg)
    }

    // Send tasks
    go func() {
        for i := 1; i <= 9; i++ {
            tasks <- Task{ID: i, Data: fmt.Sprintf("data-%d", i)}
        }
        close(tasks) // signal workers no more tasks
    }()

    // Close results when all workers are done
    go func() {
        wg.Wait()
        close(results)
    }()

    // Collect results
    for r := range results {
        fmt.Println(r.Output)
    }
}

Key takeaways

close(tasks) is essential — it signals all workers that no more tasks are coming and they should exit their range loop.
sync.WaitGroup tracks when all workers have finished so you can safely close the results channel.
Tasks are automatically load-balanced: whichever worker is free picks up the next task.

🔗 Pattern 2 — Pipeline

A pipeline chains goroutines together so the output of one stage becomes the input of the next. Each stage runs concurrently.

Generate ──► Stage 1 ──► Stage 2 ──► Consume

func generate(nums ...int) <-chan int {
    out := make(chan int)
    go func() {
        for _, n := range nums {
            out <- n
        }
        close(out)
    }()
    return out
}

func square(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        for n := range in {
            out <- n * n
        }
        close(out)
    }()
    return out
}

func main() {
    // Pipeline: generate → square → print
    c := generate(2, 3, 4, 5)
    out := square(c)

    for v := range out {
        fmt.Println(v) // 4, 9, 16, 25
    }
}

Each stage is a function that:

Receives a <-chan (read-only channel) as input.
Returns a <-chan as output.
Runs its own goroutine and closes its output channel when done.

This makes pipelines composable — you can chain as many stages as you like.

Pattern 3 — Rate Limiter

Rate limiters are critical in production systems — they prevent your service from overwhelming downstream APIs or databases.

Go's time.Tick combined with channels makes this beautifully simple:

func main() {
    requests := make(chan int, 5)
    for i := 1; i <= 5; i++ {
        requests <- i
    }
    close(requests)

    // Allow 1 request every 200ms
    limiter := time.Tick(200 * time.Millisecond)

    for req := range requests {
        <-limiter // block until the next tick
        fmt.Println("request", req, "processed at", time.Now())
    }
}

For bursty traffic (allow a burst then throttle), use a buffered ticker channel:

burstyLimiter := make(chan time.Time, 3)

// Pre-fill with 3 burst slots
for i := 0; i < 3; i++ {
    burstyLimiter <- time.Now()
}

// Refill at 1 per 200ms
go func() {
    for t := range time.Tick(200 * time.Millisecond) {
        burstyLimiter <- t
    }
}()

Common Pitfalls

Pitfall	What Happens	Fix
Forgetting `close(ch)`	Workers hang forever waiting	Always close the sender side
Closing a channel twice	Panic	Use a `sync.Once` or `defer` carefully
Sending to a closed channel	Panic	Ensure only the sender closes
Goroutine leak	Memory builds up silently	Use `context.Context` for cancellation

Running the Examples

Clone the repo and run any example:

git clone https://github.com/keyadaniel56/golang-channels
cd golang-channels

# Worker pool
cd project1-worker-pool-pattern
go run main.go task.go

# Pipeline
cd ../pipeline
go run main.go

# Rate limiter
cd ../rate-limiter
go run main.go

Summary

Pattern	Use Case
Worker Pool	CPU-bound tasks, parallel processing, job queues
Pipeline	ETL, stream processing, multi-stage transformation
Rate Limiter	API clients, database writes, external service calls

Channels are one of those features that take a little time to click — but once they do, you'll find yourself reaching for them constantly. The patterns in this repo are the building blocks behind real-world systems like message queues, web scrapers, and microservice workers.

⭐ If this was helpful, check out the full project on GitHub: golang-channels

Happy coding, and may your goroutines never leak! 🐹

Build a Real-Time Chat App with Go, Gin & WebSockets

Daniel Keya — Mon, 16 Mar 2026 11:55:35 +0000

Build a Real-Time Chat App with Go, Gin & WebSockets

WebSockets make real-time apps feel alive. In this tutorial we're going to build a fully functional multi-user chat app using Go, Gin, and Gorilla WebSocket — with sent/received message bubbles, a live online user counter, and a zero-dependency vanilla JS frontend.

The full source code is on GitHub: keyadaniel56/golang-chatapp

What We're Building

Multi-user real-time chat over WebSockets
Sent messages aligned right (yellow-green), received messages aligned left (teal)
Live "N ONLINE" counter in the header that updates instantly on join/leave
Join/leave system messages
A clean terminal-aesthetic dark UI — no frontend framework needed

Prerequisites

Go 1.22+
Basic familiarity with Go syntax
A terminal

Project Structure

golang-chatapp/
├── main.go          # All server logic
├── static/
│   └── index.html   # Frontend (vanilla JS)
├── go.mod
└── go.sum

Step 1 — Initialize the Module

mkdir golang-chatapp && cd golang-chatapp
go mod init chatapp
go get github.com/gin-gonic/gin
go get github.com/gorilla/websocket

Step 2 — The Message Type

Every piece of data flowing through the system is a Message:

type Message struct {
    Username  string `json:"username"`
    Text      string `json:"text"`
    Time      string `json:"time"`
    Type      string `json:"type"`       // "message" | "join" | "leave"
    UserCount int    `json:"user_count"` // set on join/leave events
}

The UserCount field lets the frontend update the online counter without a separate REST poll every time someone connects or disconnects.

Step 3 — The Client

Each browser tab that connects becomes a Client. It has two goroutines:

readPump — reads incoming JSON from the WebSocket and hands it off to the Hub
writePump — drains the send channel and writes JSON back to the browser

type Client struct {
    hub      *Hub
    conn     *websocket.Conn
    send     chan Message
    username string
}

func (c *Client) readPump() {
    defer func() {
        c.hub.unregister <- c
        c.conn.Close()
    }()
    for {
        var msg Message
        if err := c.conn.ReadJSON(&msg); err != nil {
            break
        }
        msg.Username = c.username
        msg.Type = "message"
        c.hub.broadcast <- msg
    }
}

func (c *Client) writePump() {
    defer c.conn.Close()
    for msg := range c.send {
        if err := c.conn.WriteJSON(msg); err != nil {
            break
        }
    }
}

When readPump exits (the browser closes or drops), it automatically fires unregister on the Hub — so the leave message and updated count get broadcast immediately.

Step 4 — The Hub

The Hub is the heart of the app. It runs in a single goroutine and is the only place that touches the clients map — no mutexes needed.

type Hub struct {
    clients    map[*Client]bool
    broadcast  chan Message
    register   chan *Client
    unregister chan *Client
}

func (h *Hub) run() {
    for {
        select {
        case client := <-h.register:
            h.clients[client] = true
            h.broadcastAll(Message{
                Username:  client.username,
                Text:      client.username + " joined the chat",
                Type:      "join",
                UserCount: len(h.clients),
            })

        case client := <-h.unregister:
            if _, ok := h.clients[client]; ok {
                delete(h.clients, client)
                close(client.send)
                h.broadcastAll(Message{
                    Username:  client.username,
                    Text:      client.username + " left the chat",
                    Type:      "leave",
                    UserCount: len(h.clients),
                })
            }

        case msg := <-h.broadcast:
            h.broadcastAll(msg)
        }
    }
}

func (h *Hub) broadcastAll(msg Message) {
    for client := range h.clients {
        select {
        case client.send <- msg:
        default:
            close(client.send)
            delete(h.clients, client)
        }
    }
}

Why no mutex? Because all reads and writes to h.clients happen inside the select statement in run(), which executes sequentially in one goroutine. The channels are the synchronization primitive.

Step 5 — Gin Routes

func main() {
    hub := newHub()
    go hub.run()

    r := gin.Default()

    r.Static("/static", "./static")
    r.GET("/", func(c *gin.Context) {
        c.File("./static/index.html")
    })

    r.GET("/ws", func(c *gin.Context) {
        username := c.Query("username")
        if username == "" {
            c.JSON(http.StatusBadRequest, gin.H{"error": "username required"})
            return
        }
        conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
        if err != nil { return }

        client := &Client{
            hub: hub, conn: conn,
            send: make(chan Message, 256),
            username: username,
        }
        hub.register <- client
        go client.writePump()
        go client.readPump()
    })

    r.GET("/api/users", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"online": len(hub.clients)})
    })

    r.Run(":8080")
}

Three routes:

/ — serves the frontend HTML
/ws?username=Alice — upgrades to WebSocket and registers the client
/api/users — returns the online count (used on initial page load)

Step 6 — The Frontend

The frontend is pure vanilla JS — no React, no Vue, just a WebSocket object and some DOM manipulation.

Connecting:

const proto = location.protocol === 'https:' ? 'wss' : 'ws';
ws = new WebSocket(`${proto}://${location.host}/ws?username=${encodeURIComponent(me)}`);

ws.onmessage = e => {
    const m = JSON.parse(e.data);
    if (m.type === 'join' || m.type === 'leave') {
        sysMsg(m.text, m.type);
        if (m.user_count !== undefined) setCount(m.user_count);
    } else {
        bubble(m);
    }
};

Rendering sent vs received bubbles:

function bubble(msg) {
    const isSelf = msg.username === me;
    const row = document.createElement('div');
    row.className = `bubble-row ${isSelf ? 'sent' : 'recv'}`;
    row.innerHTML = `
        <div class="dir-label">${isSelf ? '▲ SENT' : '▼ RECEIVED'}</div>
        <div class="bubble-meta">
            <span class="bubble-name">${esc(msg.username)}</span>
            <span class="bubble-time">${timestamp()}</span>
        </div>
        <div class="bubble">${esc(msg.text)}</div>`;
    append(row);
}

Sent messages (isSelf = true) align right with a yellow-green palette. Received messages align left with teal. The CSS does the heavy lifting:

.bubble-row.sent  { align-self: flex-end;  }
.bubble-row.recv  { align-self: flex-start; }

.bubble-row.sent  .bubble { background: #1a2604; border-color: #334d08; border-radius: 10px 2px 10px 10px; }
.bubble-row.recv  .bubble { background: #041a15; border-color: #0d3328; border-radius: 2px 10px 10px 10px; }

The asymmetric border radii (one sharp corner per bubble, on the side closest to the edge) are a subtle detail that makes sent vs received feel immediately distinct even without reading the label.

How It All Flows

Browser opens /ws?username=Alice
    → Gin upgrades to WebSocket
    → New Client created
    → hub.register ← client
    → Hub broadcasts join + user count to everyone
    → Frontend updates online counter

Alice types "hello"
    → ws.send({ text: "hello" })
    → Client.readPump reads it
    → hub.broadcast ← message
    → Hub loops all clients, pushes to send channels
    → Client.writePump writes JSON to each browser
    → Each browser renders bubble (sent=right / recv=left)

Alice closes tab
    → readPump exits, fires hub.unregister
    → Hub removes client, broadcasts leave + updated count

Running It

go mod tidy
go run main.go

Open two tabs at http://localhost:8080, enter different usernames, and start chatting. You'll see the online counter tick up to 2, and each tab will show its own messages on the right and the other person's messages on the left.

What to Build Next

Rooms/channels — add a room field to Message and maintain a map[string]*Hub
Persistence — write messages to PostgreSQL or Redis before broadcasting
Auth — validate a JWT in the /ws handler instead of accepting any ?username=
TLS — put Nginx in front and it will upgrade ws:// to wss:// automatically
Docker — the app is a single binary, a two-line Dockerfile is all you need

Source Code

GitHub: keyadaniel56/golang-chatapp

If this helped you, drop a ⭐ on the repo and share it with someone learning Go. Happy coding!

DEV Community: Daniel Keya

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

Fan-out on Write vs Read

Eventual vs Strong Consistency

Push vs Pull for Notifications

5. Back-of-Envelope Estimates

6. What Makes TikTok's Architecture Special?

Interview Tips

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

The problem

retry — automatic reattempts on failure

How it works

Usage

Why await inside try matters

timeout — give up after a deadline

How it works

Usage

Combining them

What makes these worth keeping

The pattern

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

Let's walk through it.

The code

Bug #1: comparing errors with ===

Bug #2: overwriting the parameter

Bug #3: the catch block returns undefined

A cleaner version

The three takeaways

Shared-Key Cryptosystems in JavaScript: A Practical Guide

What Is a Shared-Key Cryptosystem?

The Key Exchange Problem

Hands-On: AES-GCM in JavaScript

Step 1: Generate a Shared Key

Step 2: Encrypt a Message

Step 3: Decrypt the Message

Exporting and Importing Keys

Putting It All Together: A Complete Example

Security Considerations ⚠️

When to Use Shared-Key vs. Asymmetric Cryptography

Recap

Go Backend Frameworks: Which One Should You Actually Use?

The Contenders

1. net/http — The Standard Library

2. Gin — The Industry Standard

3. Echo — The Clean Alternative

4. Fiber — The Express.js Port

5. Chi — The Minimal Router

Head-to-Head Comparison

My Pick

The Honest Truth

What's Your Pick?

Inverting an Object in JavaScript: Swap Keys and Values

The Full Function

How It Works

Step 1 — Create an empty result object

Step 2 — Iterate with Object.entries

Step 3 — Assign with keys and values swapped

Step 4 — Return the result

Dry Run: { a: "x", b: "y", c: "z" }

Real-World Use Cases

Edge Cases to Know

Duplicate values — last one wins

Non-string values become strings

Nested objects don't invert recursively

A One-Liner Alternative

Complexity

Wrapping Up

Building a Nutrition Calculator in JavaScript: filter, map, and reduce on Objects

The Data: A Nutrition Database

`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

Step 2 — Iterate with `Object.entries`

Dry Run: `{ a: "x", b: "y", c: "z" }`

`filterEntries` — like `Array.filter` for objects

`mapEntries` — like `Array.map` for objects

`reduceEntries` — like `Array.reduce` for objects

`totalCalories` — sum calories across a cart

`lowCarbs` — filter out high-carb items

`decimalPlaces` — count decimal precision

`cartTotal` — scale all nutrients for every item

Step 3 — Walk `s1`, add unseen characters

Step 4 — Walk `s2`, add only new characters

Dry Run: `"hello"` ∪ `"world"`

Processing `s1 = "hello"`

Processing `s2 = "world"`

✅ Match: `"ace"` in `"abcde"`

❌ No Match: `"aec"` in `"abcde"`

`var`, `let`, and `const` — Why Are There Three of You?