DEV Community: D Abhiram Karanth

Stop Copy-Pasting Auth Logic. Build It Once.

D Abhiram Karanth — Sun, 01 Feb 2026 09:25:25 +0000

Authentication is one of those things every dev team rebuilds from scratch. Every. Single. Time.

App A has login? Cool. App B copies it. App C "improves" it. Fast forward six months and you've got:

Three different token formats
Two apps that don't actually log users out
One app that expires tokens after 15 minutes for "security"
Zero chance of sanity

There's a better way.

I built Auth-Flow — a centralized authentication service in Go that you build once and reuse everywhere.

GitHub: https://github.com/abhiram-karanth-core/auth-flow

The Problem With Scattered Auth

Here's how most teams handle authentication:

Copy auth code from the last project
Tweak it slightly for "this app's needs"
Ship it
Repeat for the next service

This works... until it doesn't.

Eventually you hit the wall:

Can't revoke tokens across services
Logout doesn't actually work
Every service has different expiration rules
Nobody remembers which app stores passwords how

Auth shouldn't be copypasta. It should be infrastructure.

What Auth-Flow Does

Auth-Flow is a standalone service that handles:

OAuth 2.0 (starting with Google, easily extensible)
JWT minting with proper claims
Real logout (yes, actually works)
Token revocation via Redis
Stateless validation for your other services

Your apps don't handle auth anymore. They just trust this service.

How It Works

Auth-Flow supports two authentication paths:

Option 1: OAuth Flow (Google)

User clicks "Login with Google"
Auth-Flow redirects to Google
Google sends back an auth code
Auth-Flow exchanges it for user info
Auth-Flow mints a signed JWT
Client gets the token

Option 2: Custom Authentication (`/mint`)

Already verified a user through your own system? Just call /mint:

POST /mint
Content-Type: application/json

{
  "sub": "username",
  "provider": "local",
  "email": "user@example.com"
}

Auth-Flow returns a JWT - no questions asked.

This is the key design decision: Auth-Flow doesn't care how you authenticated the user. It only cares about issuing and revoking tokens consistently.

No passwords stored. No session cookies. Clean.

The Real Problem: Logout

Here's the dirty secret about JWTs: they don't support logout.

JWTs are stateless. You can't "delete" them. Once issued, they're valid until expiration.

Most tutorials ignore this. Real systems can't.

The Fix: Redis + Token IDs

Every JWT gets a unique ID (jti). When someone logs out:

Store the jti in Redis with TTL matching token expiration
Middleware checks Redis on every request
If jti exists in Redis, token is revoked, return 401

Result:

Instant logout across all services
No central session store
Still horizontally scalable

This is the part most auth libraries skip. Auth-Flow handles it out of the box.

Core Endpoints

GET  /auth/{provider}
GET  /auth/{provider}/callback
POST /mint
POST /logout

Your other services just need lightweight middleware:

Verify JWT signature
Check Redis for revocation
Extract user claims

That's it.

Why Go?

Go is perfect for auth infrastructure:

Fast startup — runs in milliseconds
Low memory — handles thousands of requests on minimal resources
Built for concurrency — handles OAuth callbacks + Redis + validation in parallel
Simple — the whole service is around 500 lines, easy to audit

Plus: excellent libraries for OAuth, JWT, and Redis. No framework bloat needed.

When Should You Use This?

This pattern makes sense if you have:

Multiple backend services (microservices, modular monoliths, etc.)
Web + mobile clients
Any need for SSO or centralized user management
An allergy to reimplementing auth every sprint

Not a fit if:

You have one tiny service and that's it
You're prototyping and don't care about logout
You want to store passwords locally (please don't)

What's Next

Roadmap ideas:

Refresh tokens (currently just access tokens)
Role-based permissions in JWT claims
Support for GitHub, Azure AD, custom OIDC providers
Admin API for token introspection
Rate limiting on auth endpoints

Final Thoughts

Authentication isn't app logic. It's infrastructure.

Stop rebuilding it. Stop copying it. Build it once, properly, and move on.

Auth-Flow gives you:

OAuth out of the box
Real logout that actually works
One source of truth for tokens
Less code in every other service

If you're running distributed systems, this saves time, reduces bugs, and keeps security consistent.

Check it out: https://github.com/abhiram-karanth-core/auth-flow
Also: https://auth-flow-v1.vercel.app/docs

Got questions? Built something similar? Hate this approach? Drop a comment. I read 'em all.

How I built horizontally scalable chat server in Go

D Abhiram Karanth — Sat, 31 Jan 2026 17:13:41 +0000

How I built a horizontally scalable chat server in Go.

It's not about sending messages fast.
It's about doing three things at once:
— deliver in real time
— preserve order + durability
— scale without sticky sessions

Project: Signal-Flow

GitHub: https://github.com/abhiram-karanth-core/signal-flow

Demo: https://global-chat-app-web.vercel.app/

Here's how I broke it down

The key insight: stop treating a chat message as one thing.

Every message has a lifecycle with very different requirements at each stage. Collapsing them into one system is where most chat servers break down at scale.

The lifecycle:

User sends a message (Next.js)
Go WebSocket server receives it
Made durable (Kafka)
Fanned out to other users (Redis)
Written to queryable history (Postgres)

Each step needs a different system. Each system does exactly one job.

The first big lesson: real-time delivery and durable storage have opposing needs.

Real-time = sub-millisecond latency
Durable = safety, ordering, replayability

Forcing one system to do both means compromising on both. So don't.

Kafka is the source of truth. Every message hits Kafka first — before fan-out, before anything.

But Kafka doesn't deliver messages to users. It exists so the system can survive failures and recover state.

Correctness lives here. Latency does not.

Why partition by room?

Message ordering matters — but only within a room, not globally.

Kafka guarantees ordering per partition, so messages are partitioned by room_id.

Each room maps deterministically to a single partition, preserving strict ordering
for that room while allowing horizontal throughput across rooms.

Per partition → ~5k msg/sec

N partitions → ~N × 5k msg/sec across independent rooms

This keeps chat semantics correct and scales throughput without global bottlenecks.

Redis makes it feel instant.

It sits on the hot path — performing room-based fan-out so that each WebSocket connection independently receives messages for its subscribed room.

Redis is intentionally ephemeral. If it drops a message: Kafka still has it. Clients recover on reconnect. History stays correct.

Postgres makes it usable.

Kafka consumers write to Postgres asynchronously. This means:
— DB slowness never blocks ingestion
— State can be rebuilt from Kafka replay
— Frontend reloads always return consistent history

Postgres is the materialized view users actually interact with.

The most important architectural decision: heavy decoupling between consumers.

Kafka → Redis (real-time fan-out)
Kafka → Postgres (durable writes)

Producer publishes once. Doesn't care who consumes. Each consumer fails and restarts independently.

No cascading failures.

Why it scales horizontally:

— Go servers are stateless (no sticky sessions)
— Real-time delivery is decoupled from durability
— Each component has one job
— Any component can rebuild from Kafka replay

Scaling becomes an ops concern. Not an app rewrite.

The frontend never sees any of this.

WebSockets → real-time updates via Redis
HTTP APIs → message history from Postgres
Kafka stays internal. Clean boundary.

Don't build a chat server. Build three systems that each do one thing well:

Kafka → correctness
Redis → latency
Postgres → usability

Everything else is trade-offs.