As a software engineer, a personal website is more than just an online resume it’s an open-ended canvas, a sandbox for testing new tech, and a reflection of how you approach software architecture.

When I set out to build shubhkumar.in, I didn't want to just spin up a template or use a no-code builder. I wanted to build a production-grade, highly optimized, and scalable platform from scratch.

Here is a look under the hood at the stack, the design decisions, the hosting setup, and the inevitable mistakes made along the way.

The Tech Stack: Modular & Decoupled

Instead of building a monolithic application, I opted for a decoupled frontend and backend architecture. This keeps the presentation layer lightweight while allowing the API to scale independently.

• Frontend: Next.js & Tailwind CSS. Next.js handles the user interface with excellent performance, while Tailwind CSS keeps the utility-first design clean, responsive, and highly maintainable.

• Backend API: Express.js (Node.js). Hosted at api.shubhkumar.in, this unopinionated framework handles dynamic requests and serves content efficiently.

• Database & Distributed Caching: MongoDB Atlas & Redis. MongoDB Atlas acts as our fully managed cloud database layer. To slash latency and prevent unnecessary database queries, a cloud-managed Redis instance sits right in front of it.

Design Decisions: Single Source of Truth & Multi-Tier Caching

The core philosophy behind this project was performance, reusability, and absolute separation of concerns.

Instead of letting the Next.js frontend query the database directly, everything routes through the dedicated Express API. The biggest architectural win here is that the API acts as a single source of truth for my entire digital footprint.

Beyond the main portfolio at shubhkumar.in, I also host my dedicated CV at cv.shubhkumar.in. Both frontends consume data from the exact same API endpoints. If I update a project description, add a new tech stack proficiency, or modify my work history, the change reflects universally across all subdomains.

To deliver instantaneous, sub-100ms response times globally, the architecture leverages a two-tier aggressive caching model:

1. The API Tier (Redis): When a request hits the Express backend, it checks the cloud Redis cache first. If it's a hit, it serves it instantly. If it's a miss, it pulls from MongoDB Atlas and hydrates Redis with an expiration TTL (Time-to-Live).

2. The Frontend Tier (Next.js Data Cache): Pages aren't just fetching live on every request. Next.js caches data at the framework layer using time-based revalidation (next: { revalidate: ... }). This serves prerendered static pages from Vercel’s edge network while quietly updating the data in the background once the timer lapses.

Hosting & Deployment: The Cloud Setup

For hosting, I wanted a fully managed, modern cloud setup that eliminates infrastructure maintenance overhead while providing global scalability.

• Frontend Hosting (Vercel): The Next.js frontend is deployed on Vercel, providing global CDN distribution and world-class optimization for Next.js assets out of the box.

• Backend Hosting (Render): The Express.js API runs on Render, managing web environments smoothly with auto-deployments from Git and managed SSL setup.

• Health & Diagnostics (Uptime Monitoring): To ensure high availability across this distributed setup, I implemented a robust uptime monitoring layer that pings the frontend endpoints and the underlying API services, alerting me the second a bottleneck occurs.

Mistakes I Made (And How I Fixed Them)

No project is built from scratch without a few roadblocks. Here are the major pitfalls I encountered:

1. The Double-Caching Sync Dilemma: Layering Next.js revalidation over an aggressive Redis cache meant that content updates were trapped behind two separate timers. Modifying database records sometimes wouldn't show up on the live UI for quite a long time due to cache stacking.

*   _The Fix (and Current Plan):_ Right now, the site relies on short, balanced time-to-live intervals. However, the long-term solution is already in the works: building a unified dynamic webhook pipeline. When data changes, a hook will trigger an automatic `DEL` command to the Redis key and simultaneously ping a Next.js API route handler to call `revalidatePath()` or `revalidateTag()`, flushing both layers instantly.

1. Over-Engineering the Backend Initially: I started treating my personal API like an enterprise microservices platform, worrying about premature optimization before the core features were even stable.

*   _The Fix:_ I stripped it back to a clean, modular Express architecture. YAGNI (You Aren't Gonna Need It) applies to personal portfolios just as much as production SaaS products.

1. Handling Cold Starts on Managed Hosting: When the API instances go quiet, spin-up times on managed cloud infrastructure can sometimes introduce latency for the first visitor.

*   The Fix: I streamlined database connection pools, minimized the deployment bundle, and utilized the uptime monitoring pings as a dual-purpose "heartbeat" to ensure the API container stays warm, active, and snappy.

Final Thoughts

Building shubhkumar.in from scratch wasn't the fastest way to put a portfolio online, but it was easily the most rewarding. It forced me to think through the entire lifecycle of an application from building a multi-tier cache architecture to managing production cloud deployments.

The best part? Because it’s driven by a single-source-of-truth API, it can power any future side project or subdomain I decide to build down the road.