DEV Community: CHRISTIAN OTIENO

Demystifying JWTs: What Actually Happens Under the Hood published: true tags: webdev, security, javascript, architecture

CHRISTIAN OTIENO — Mon, 14 Sep 2026 16:11:44 +0000

JSON Web Tokens (JWTs) are practically everywhere. We reach for them when building microservices, mobile APIs, and single-page apps.

Yet when asked how they actually work under the hood, the standard developer answer usually defaults to:

"It's a signed string you store in localStorage and pass along in an Authorization header."

Let’s dismantle that abstraction. A JWT is not encrypted by default, it is rarely magic, and implementing it blindly introduces real security headaches.

Here is what is actually going on under the hood.

The Anatomy of a JWT
A JWT is fundamentally a single string divided into three distinct segments separated by dots (.):

Plaintext

header.payload.signature
_
Every segment is encoded using Base64Url—not encrypted. Anyone who intercepts the token can paste it into an online decoder and inspect the data instantly.

Let’s break down the three parts.

The Header The header contains metadata about the token: the type and the cryptographic algorithm used to secure it.

JSON
{
"alg": "HS256",
"typ": "JWT"
}

alg: The signing algorithm (e.g., symmetric algorithms like HS256, or asymmetric key pairs like RS256).
typ: Almost universally set to "JWT".
The Payload
The payload contains the claims—statements about the user and context the server needs to function statelessly.

JSON
{
"sub": "usr_94810284",
"name": "Jane Doe",
"role": "admin",
"iat": 1711926000,
"exp": 1711929600
}
Claims fall into two primary buckets:

Registered claims: Standardized keys like sub (subject/user ID), iat (issued-at timestamp), and exp (expiration timestamp).

Custom claims: Application-specific context like role, tenant_id, or access scopes.

⚠️ Critical Security Rule: Never store sensitive data (passwords, private API keys, or unencrypted PII) inside a JWT payload. Encoding is not encryption.

The Signature This is the integrity anchor of the entire token. The signature prevents tampering.

To generate it, the issuing server takes the Base64Url-encoded header, appends the Base64Url-encoded payload, and hashes them using a private secret:

JavaScript
const signature = HMACSHA256(
${base64UrlEncode(header)}.${base64UrlEncode(payload)},
SERVER_SECRET_KEY
);
When a client sends the token back, the server re-runs that exact calculation. If the newly calculated signature matches the signature attached to the token, two things are guaranteed:

Integrity: The header and payload were not altered in transit.

Authenticity: The token was issued by an entity holding the secret key.

The Lifecycle of a Stateless Request
Here is the complete authentication flow in practice:

[ Client ] [ Server ]
| |
|---- 1. POST /api/login (Credentials) ------------->|
| |-- Validates credentials
| |-- Signs JWT with secret
|<--- 2. Returns JWT (Set-Cookie / Body) ------------|
| |
|---- 3. GET /api/dashboard (Bearer ) ------->|
| |-- Recomputes signature
| |-- Checks exp timestamp
| |-- Serves data (Zero DB lookups!)
|<--- 4. HTTP 200 OK --------------------------------|
Authentication: The client submits credentials to /api/login.

Issue: The server checks credentials against the database, builds the claims payload, signs it with its secret, and returns the token.

Storage: The client stores the token (preferably in an httpOnly, Secure, SameSite cookie to mitigate XSS attack vectors).

Transport: Subsequent calls pass the token via the Authorization header:

HTTP
Authorization: Bearer eyJhbGciOi...
Stateless Verification: The server recomputes the signature using its secret and checks the exp timestamp. If valid, the request proceeds—without querying a session database.

Architectural Trade-offs: When NOT to Use Pure JWTs
Statelessness makes horizontal scaling easier, but it introduces tradeoffs that standard tutorials gloss over:

Feature Session IDs (Stateful) JWTs (Stateless)
Revocation Instant (delete record from Redis/DB). Difficult (valid until exp triggers).
Payload Size Tiny (~32-character pointer string). Larger (carries claims on every request).
DB / Cache Load Hit on every authenticated request. Zero DB lookups for validation.
Server Sync Requires shared session store. Any service with the key/public key can verify.
The Revocation Problem
If a user changes their password, reports a compromised account, or gets suspended, an issued JWT remains completely valid until its exp time passes.

To fix this in production, architectures commonly use:

Short-lived access tokens (5–15 minutes) combined with stateful refresh tokens stored securely in a database.

Revocation blocklists in Redis (which sacrifices pure statelessness).

Core Takeaways
Base64Url is encoding, not encryption. Don't hide secrets in the payload.

Signatures ensure integrity, not secrecy. They only prove the data hasn't been modified.

Statelessness is a double-edged sword. Build an explicit revocation strategy before relying on JWTs in production.

Over to you: How does your team handle token invalidation? Are you pairing short-lived access tokens with refresh tokens, or relying on centralized session stores like Redis? Let's discuss in the comments below!

Beyond the Monolith: A Practical Guide to Database Sharding

CHRISTIAN OTIENO — Sat, 29 Aug 2026 10:37:56 +0000

Table Of Contents
1.Introduction: When Scaling Up Hits a Wall
2.What Is Database Sharding?
3.Core Sharding Architectures & Routing Strategies
4.The Operational Hidden Costs of Sharding
5.When Should You Actually Shard?
6.Conclusion

Introduction: When Scaling Up Hits a Wall

Every growing application eventually hits a point where vertical scaling—throwing more CPU, RAM, and faster NVMe drives at a single database instance—stops being economically or physically viable. When your primary relational database hits storage limits, IOPS bottlenecks, or connection pool saturation, horizontal scaling becomes the inevitable next step.

Enter database sharding.

While sharding solves massive throughput and storage constraints, it introduces a whole new class of distributed systems complexities. Let's break down how sharding actually works, the architectural patterns you can choose, and the hidden operational costs you need to weigh before splitting your data.

What Is Database Sharding?

At its core, sharding is a shared-nothing horizontal partitioning strategy. Instead of keeping all rows of a massive table in a single database instance, you split the rows across multiple independent databases (called "shards").

Each shard holds a subset of the total data, and the union of all shards makes up the complete dataset.

           [ Application / Router Layer ]
          /              |              \
         /               |               \
        v                v                v
  [ Shard 1 ]      [ Shard 2 ]      [ Shard 3 ]
 (Users A-H)      (Users I-P)      (Users Q-Z)

Unlike read replicas (which duplicate the entire dataset for read scaling), shards actively partition write and storage workloads, allowing your infrastructure to scale out linearly.

Core Sharding Architectures & Routing Strategies

How do you decide which shard a piece of data belongs to? Your routing strategy dictates how queries find their target nodes.

Range-Based Sharding

Data is partitioned based on predefined ranges of a column value. For example, user IDs 1 to 1,000,000 go to Shard A, and 1,000,001 to 2,000,000 go to Shard B.

Pros: Simple to implement; highly efficient for range queries (e.g., WHERE created_at BETWEEN ...).
Cons: Prone to hotspotting. If most of your incoming traffic targets newly created users, Shard B will absorb 90% of the write load while older shards sit idle.

Hash-Based Sharding

An application or database proxy passes a sharding key (like a user_id or tenant_id) through a hash function (such as MurmurHash), and applies a modulo operation to determine the target shard index.

Conceptual hash routing example

shard_count = 4
user_id = 849203
shard_index = hash(user_id) % shard_count
Pros: Evenly distributes data and write load across all available shards, eliminating hotspots.
Cons: Extremely painful to scale out. If you add a fifth shard, changing the modulo math requires a massive data migration (re-sharding) to redistribute existing keys. (Consistent hashing algorithms help mitigate this, but add architectural overhead).

Directory-Based Sharding

You maintain a centralized lookup table (or service) that tracks which entity lives on which shard.

Pros: Highly flexible; you can manually move individual tenants or users to different shards for load balancing.
Cons: The directory lookup becomes a single point of failure (SPOF) and an extra network hop for every single query.

The Operational Hidden Costs of Sharding

Before you commit to sharding your database, you must accept the distributed systems trade-offs. Sharding breaks several guarantees that monolithic SQL databases provide out-of-the-box:

Cross-Shard Joins are Painful: If users live on Shard 1 and their corresponding orders live on Shard 2, joining those tables requires application-level orchestration, scatter-gather queries, or distributed transactions (two-phase commit), which heavily degrades performance.

Global Uniqueness Constraints: Enforcing a unique constraint (like an email address or username) across multiple independent databases requires a centralized ID generation service (like Twitter Snowflake or centralized Redis counters).

Re-balancing and Resharding: As your data grows unevenly, splitting an overloaded shard into two requires careful planning, dual-writes, and zero-downtime data migration pipelines.

When Should You Actually Shard?

The golden rule of database sharding is simple: Don't do it until you absolutely have to.

Exhaust all other optimization paths first:

Optimize your indexing and query execution plans.
Implement aggressive caching layers (e.g., Redis or Memcached).
Offload read traffic using read replicas.
Purge or archive cold/historical data into cheaper cold storage.
If you have genuinely maxed out vertical scaling, saturated your primary write IOPS, and your dataset spans hundreds of gigabytes or terabytes where partitioning by tenant makes logical sense—then sharding is your answer.

How does your team handle database scaling bottlenecks? Have you ever migrated a monolith to a sharded architecture, and what was your biggest lesson learned? Let me know in the comments below!

AI Can Build Your UI—But Can It Maintain It?

CHRISTIAN OTIENO — Wed, 17 Jun 2026 17:42:02 +0000

AI coding agents have moved way past simple autocomplete. Anyone can prompt an agent to build a clean dashboard component. But what happens six months later when dependencies shift, state management gets tangled, or accessibility breaks?

ASCII ART

CHRISTIAN OTIENO — Wed, 17 Jun 2026 17:29:45 +0000

Why ASCII Art is Still the Ultimate Dev Nostalgia.
If you’ve ever opened a new terminal tool, checked a repository's README.md, or looked closely at a well-documented source code file, chances are you’ve run into ASCII art.

While it feels like a relic of the 1980s BBS board era, this text-based design medium is still alive, kicking, and surprisingly practical in modern development.

What is ASCII Art?
At its core, ASCII art is a graphic design technique that uses printable characters from the ASCII standard (letters, numbers, and symbols like /, \, |, _) to piece together visual images.

Before high-resolution displays and modern GPUs, this was how developers added personality, logos, and diagrams to text-only screens.

Why Do Developers Still Use It?
Zero Overhead: It requires no image hosting, no external assets, and zero loading time. It’s just plain text.

Terminal Branding: Popular CLI tools (like Homebrew, Docker, or Neofetch) use ASCII splash screens to build an instant, recognizable brand right in your terminal.

Code Organization: Massive codebases sometimes use giant ASCII headers to separate major sections in a single source file, making it easy to spot sections while scrolling fast.

Pure Nostalgia: Let’s honest—it just looks incredibly cool and gives off peak hacker vibes.

Quick Tools to Generate Your Own
You don’t have to manually type out every backslash. Here are the quickest ways to add some flavor to your next project:

FIGlet: A classic command-line tool that turns ordinary text into large, stylized ASCII banners.

TAAG (Text to ASCII Art Generator): An awesome web-based tool with hundreds of fonts to preview your text instantly.

Image-to-ASCII Converters: Tools like jp2a can take an actual .jpg or .png logo and translate it into a grayscale-like block of text.

The Takeaway
ASCII art is a bridge between computing's past and present. Next time you build an open-source tool, consider throwing a custom ASCII logo into your README or CLI startup script. It’s a small, fun touch that shows you care about the details.

Do you use ASCII art in your project configs or CLIs? Drop your favorite generator or your terminal setups in the comments below!