AI-Microservices-Job-Portal: HireHeaven: A Job Portal That Treats Authentication Like Infrastructure

Inside a microservices job platform where Redis revokes tokens, a gateway streams files without buffering them, and Kafka handles the work that should not block the request path.

8 to 10 min read • View on GitHub • More from AyushCipher

A wide operations floor for a job platform, drawn like a mechanical dispatch center. A locked gateway sits at the middle, a sealed resume envelope moves through a narrow corridor, a revoked token is pushed toward a Redis vault, and a Kafka rail carries message cars into a side room. The image explains that the repo is built around routing, revocation, and async work rather than a simple portal UI. — HireHeaven turns ordinary hiring flows into infrastructure problems, then solves them with separate services and shared plumbing.

Key Takeaways

HireHeaven stands out because it treats a job portal like a distributed system, not a CRUD app.
Its most interesting trick is server-side token revocation, which turns JWT logout into a real security boundary.
The gateway is doing operational work, including streaming uploads and shaping traffic, instead of acting as a passive router.
Shared packages, Redis, Kafka, and service boundaries keep the repo coherent enough to feel production-minded rather than demo-sized.

Most job portals are built to prove they can store postings, accept applications, and maybe call an LLM. HireHeaven is more interesting because it asks a different question: what if the boring hard parts were the product? The repo is full of the concerns that usually get skipped in portfolio builds, from revocable auth to cache invalidation to async side effects.

The Job Portal That Refuses to Behave Like a Demo

The project is a microservices monorepo with a Next.js frontend, Express services, Redis, Kafka, PostgreSQL, Cloudinary, Razorpay, and Gemini. That stack could have been chaotic. Instead, the repo uses service boundaries and shared infrastructure to make the system feel intentional.

That is the core surprise. HireHeaven does not just bolt AI onto a hiring site. It treats auth, uploads, notifications, caching, and observability like first-class systems concerns.

applied to a job and then was able to access their AI-generated review of my CV directly through their job portal. Cool!

gnatmaster, _natastrophe_ · @_natastrophe_ on X

Why True Logout Is the Real Headline

JWTs are convenient because they look stateless. The catch is revocation. Once issued, a token can keep working until it expires unless you add a server-side escape hatch. HireHeaven adds that escape hatch with a `jti`-based blacklist in Redis, so logout actually means something.

This flow shows why the repo feels operationally mature. Requests are routed, checked, cached, or queued based on what they need, not forced through one generic path.

// token blacklist flow
const tokenId = payload.jti;
const key = `blacklist:${tokenId}`;
await redisClient.set(key, "revoked", {
  EX: ttlSeconds,
});

const isRevoked = await redisClient.exists(key);
if (isRevoked) {
  throw new Error("Token revoked");
}

That pattern matters because it restores control. A user can log out, and the old token becomes useless. The system also avoids pretending that all auth problems are solved by signed claims alone.

A close-up security checkpoint where a paper JWT badge with a serial number approaches a turnstile. One lane is cleared because Redis has no blacklist entry, and the other is blocked because a revoked stamp has already been applied. A small clock nearby indicates token lifetime. The image explains how server-side revocation turns JWTs from purely stateless credentials into controlled sessions. — The repo’s auth design is simple to explain and hard to get right: a JWT can be valid cryptographically and still be refused by Redis.

The Gateway Is Not Just a Router

The gateway is doing real work. It proxies requests, applies rate limiting, and deliberately avoids body parsing so multipart uploads can stream through untouched. That choice sounds small until you remember how many apps accidentally break file handling by buffering everything too early.

This is the right kind of gateway. It does not become a mini-monolith. It stays just smart enough to shape traffic, protect services, and keep large uploads moving.

Pattern	How it usually works	What HireHeaven does instead	Why it matters
Auth	A token is issued and trusted until expiration.	JWTs carry a `jti`, and Redis can revoke them server-side.	Logout becomes immediate, not aspirational.
File uploads	A gateway buffers the whole body before forwarding it.	The gateway avoids body parsing so multipart data can stream through.	Large uploads stay intact and efficient.
Async work	Notification and email logic sits inside the request path.	Kafka carries side effects like send-mail events.	The app stays responsive under load.
Cache invalidation	Teams clear keys manually or too broadly.	Shared helpers invalidate by prefix with Redis scans.	Services stay consistent without duplicate logic.
AI integration	A model call is wired directly into the UI.	Gemini lives behind a utils service boundary.	The model can change without rewriting the app.
Observability	Logging and metrics are optional extras.	Structured logging and metrics are built into the services.	The system is easier to debug and operate.

Shared Infrastructure Keeps the Services From Drifting Apart

Microservices can rot into copy-paste with network calls. HireHeaven avoids that by putting the unglamorous code in `packages/common`. Token helpers, cache wrappers, logging, metrics, and shared Redis or Kafka clients keep the services consistent.

That matters because the system is only useful if the pieces behave the same way. Shared helpers make rate limiting, cache invalidation, and error handling feel like platform behavior instead of ad hoc service decisions.

Layer	Risk if duplicated everywhere	What the shared package does	Result
Token handling	Each service invents its own auth edge cases.	Centralizes JWT utilities and revocation logic.	Security stays aligned.
Caching	Key naming and invalidation drift over time.	Provides cache-aside helpers and prefix invalidation.	Fewer stale reads.
Logging	Logs become noisy and inconsistent.	Standardizes structured logging.	Debugging gets easier.
Metrics	Each service exposes different signals.	Shares common observability patterns.	Operations become comparable.
Kafka and Redis clients	Connection logic gets repeated.	Creates reusable client setup.	Less boilerplate, fewer mistakes.

AI Lives in a Service, Not a Button

The `utils` service is the right place for Gemini. It keeps AI concerns behind an API boundary, where resume analysis and career guidance can evolve without spreading model-specific code through the rest of the system. That is the difference between an AI feature and an AI architecture.

This is also where the repo avoids the common trap of making the model the point. Here, the model is just one dependency inside a broader workflow. The value is in how that workflow is routed, validated, cached, and observed.

Everyone’s still arguing about which model is “best.” GPT. Claude. Gemini. DeepSeek. Cool. But that’s just one part of the infrastructure businesses need. Real companies don’t run on one model. They run on 40 systems, 200 workflows, and people who need the AI to actually talk

Luis Loaiza, luisloaiza · @luisloaiza on X

Pattern	Typical version	HireHeaven version	Why it matters
AI	A model call in a page or component.	A dedicated utils service behind the gateway.	The app stays modular.
Validation	Inputs are trusted too early.	Zod validates at the boundary.	Bad data fails fast.
Errors	Try-catch is scattered and inconsistent.	Controllers use wrapper patterns.	Failures are easier to reason about.
Deployment	One big app is harder to move safely.	Each service has its own Dockerfile.	The stack scales by component.

What This Repo Gets Right About Production

The maturity signal is not one feature. It is the accumulation of small decisions: rate limiting in the gateway, Redis-backed revocation, Kafka topics created programmatically, role-based access, Zod validation, structured logs, and metrics endpoints. Those pieces tell you the author is thinking about day-two operations, not just the demo loop.

The comparison to a typical job board is clear. A normal portal mostly stores data. HireHeaven moves data, protects it, caches it, invalidates it, and ships side effects out of band. That is why it reads less like a school project and more like a compact systems exercise.