DEV Community: Osaf Ali Sayed

How I Built My Personal Blog & Portfolio

Osaf Ali Sayed — Fri, 04 Sep 2026 04:19:02 +0000

You might be reading this blog on my personal website, which also serves as my portfolio. I use this space to document what I’m building, the decisions I make, and the things I learn along the way as a freelancer.

In this article, I’ll walk through the architecture and implementation of my blog, with one key constraint:

Everything had to be free, portable, and fully under my control.

This blog is aimed at developers who want a zero-cost personal blog without relying on heavy CMS platforms or paid infrastructure.

Goals & Requirements

Before writing any code, I defined a few non-negotiable requirements:

No paid services (no hosting bills, no subscriptions)
Content should live in my Git repository
Easy to migrate or rebuild anytime
Write blogs in Markdown
Track blog views to understand reach
Fast loading, SEO-friendly

In short: I wanted a developer-first blog with full ownership.

System Architecture

The entire system is designed around one core idea:

Everything starts and ends with Git.

There is no traditional backend, no database, and no runtime server logic. The whole blog is built and served as static files.

High-level Flow:

I write or edit blogs using Decap CMS.
Decap commits Markdown files directly to my GitHub repository.
A GitHub Action is triggered on every push.
The action runs a build step that generates static pages.
The built site is deployed to www.osafalisayed.com.

Users access the site as plain static HTML.

Markdown → Git → Build → Static Website → User

Content Pipeline

Decap CMS is only responsible for one thing:
creating Markdown files and pushing them to Git.

There is:

No external CMS backend
No database
No API calls

GitHub itself becomes my content store, version control system, and backup.

This makes migration trivial:

If Git exists, my entire blog exists.

Build & Deployment


name: Deploy Next.js site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["master"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

  repository_dispatch:
    types: [trigger-deploy]

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Detect package manager
        id: detect-package-manager
        run: |
          if [ -f "${{ github.workspace }}/yarn.lock" ]; then
            echo "manager=yarn" >> $GITHUB_OUTPUT
            echo "command=install" >> $GITHUB_OUTPUT
            echo "runner=yarn" >> $GITHUB_OUTPUT
            exit 0
          elif [ -f "${{ github.workspace }}/package.json" ]; then
            echo "manager=npm" >> $GITHUB_OUTPUT
            echo "command=ci" >> $GITHUB_OUTPUT
            echo "runner=npx --no-install" >> $GITHUB_OUTPUT
            exit 0
          else
            echo "Unable to determine package manager"
            exit 1
          fi
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: ${{ steps.detect-package-manager.outputs.manager }}
      - name: Setup Pages
        uses: actions/configure-pages@v5
        with:
          # Automatically inject basePath in your Next.js configuration file and disable
          # server side image optimization (https://nextjs.org/docs/api-reference/next/image#unoptimized).
          #
          # You may remove this line if you want to manage the configuration yourself.
          static_site_generator: next
      - name: Restore cache
        uses: actions/cache@v4
        with:
          path: |
            .next/cache
          # Generate a new cache whenever packages or source files change.
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json', '**/yarn.lock') }}-${{ hashFiles('**.[jt]s', '**.[jt]sx') }}
          # If source files changed but packages didn't, rebuild from a prior cache.
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json', '**/yarn.lock') }}-
      - name: Install dependencies
        run: ${{ steps.detect-package-manager.outputs.manager }} ${{ steps.detect-package-manager.outputs.command }}
      - name: Build with Next.js
        run: ${{ steps.detect-package-manager.outputs.runner }} next build
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./out

  # Deployment job
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Every push to the repository triggers a GitHub Action.

That action:

Triggers the build process
Generates static pages
Outputs a fully built website
Deploys it on Github Pages

This is pure Static Site Generation (SSG):

No runtime rendering
No cold starts
No server load

The final output is just static files served to the user.

Analytics & View Tracking

For tracking blog views, I use PostHog.

The flow is:

Users visit my website.
A lightweight PostHog script tracks page views.
Once a week, a GitHub Action pulls view stats.
These stats are used during the next build, which is triggered in the same workflow.

This keeps analytics:

Completely decoupled from content
Non-blocking for performance
Invisible to the core system

Why This Architecture Works So Well

This setup gives me:

Zero hosting cost
No backend maintenance
Full ownership of content
Instant page loads
No vendor lock-in

And most importantly:

My blog is just files and code.

Which means I can rebuild it anywhere, anytime.

Content Management: Why Decap CMS

The first real decision was: How do I write my blogs?

Most CMS options fell into two categories:

Paid
free but locked into an ecosystem

Since I already write most of my notes in Markdown, I wanted something that:

Supports Markdown natively
Doesn’t require a separate backend
Can run locally

That’s why I chose Decap CMS.

It lets me:

Write Markdown visually if I want
Store everything directly in Git
Keep my workflow simple

As I scale, I can even host Decap remotely and write from anywhere - but without changing my architecture.

Why I Didn’t Use a Database

I considered options like Supabase and Firebase, but storing Markdown articles in a relational database felt wrong.

At my current stage:

I don’t need real-time features
I’m not tracking likes or comments
I just need content + pages

A Git repo already gives me:

Version history
Backup
Portability

So I kept it simple.

Rendering Markdown with Static Site Generation

Once the content lives in Git, the next problem is:

How do I turn Markdown into real pages?

The solution is Static Site Generation (SSG).

During build time:

The app reads all Markdown files
Parses them using remark
Enhances code blocks with rehype-highlight

Generates one static page per blog

This means:

No server rendering
No database queries
No cold starts

Everything is pre-built and served as plain HTML.

This is done using the generateStaticParams method in Next.js:


export async function generateStaticParams() {
  const slugs = getAllPostSlugs();
  return slugs.map((slug) => ({
    slug: slug,
  }));
}

followed by a simple getAllPostSlugs function, which fetches all the post slugs based on file names from the content directory


export function getAllPostSlugs() {
  try {
    ensurePostsDirectory();
    const fileNames = fs.readdirSync(postsDirectory);
    return fileNames
      .filter(name => name.endsWith('.md'))
      .map(name => name.replace(/\.md$/, ''));
  } catch (error) {
    console.error('Error reading posts directory:', error);
    return [];
  }
}

Once you have all the content of a blog in markdown, you simply convert it into HTML using remark and finally render it by creating a BlogContent component. The entire purpose of this component is to basically make sure the right things are highlighted and styled properly based on your site design.


'use client';

import { useEffect, useRef } from 'react';

export default function BlogContent({ contentHtml }) {
  const contentRef = useRef(null);

  useEffect(() => {
    if (contentRef.current) {
      const preElements = contentRef.current.querySelectorAll('pre');

      preElements.forEach((pre) => {
        if (pre.querySelector('.copy-button-container')) return;

        pre.style.position = 'relative';
        pre.classList.add('group');
        // Ensure there's room at the top for the language badge (in case global CSS wasn't loaded yet)
        pre.style.paddingTop = pre.style.paddingTop || '1.25rem';

        const codeElement = pre.querySelector('code');

        // Ensure .hljs class is present so our CSS rules apply (rehype-highlight usually adds this)
        if (codeElement && !codeElement.classList.contains('hljs')) {
          codeElement.classList.add('hljs');
        }

        // Determine language from class (e.g. language-python)
        let lang = '';
        if (codeElement && codeElement.className) {
          const classes = codeElement.className.split(/\s+/);
          for (const c of classes) {
            if (c.startsWith('language-')) {
              lang = c.replace('language-', '');
              break;
            }
          }
        }

        // Language badge (left)
        if (lang) {
          const langBadge = document.createElement('span');
          langBadge.className = 'language-badge absolute top-[0.25rem] left-2 text-[10px] font-mono text-neutral-300 bg-white/5 px-1.5 rounded';
          langBadge.textContent = lang;
          pre.appendChild(langBadge);
        }

        // Copy button container (right)
        const buttonContainer = document.createElement('div');
        buttonContainer.className = 'copy-button-container absolute top-2 right-2 opacity-0 group-hover:opacity-100 transition-opacity';

        const button = document.createElement('button');
        button.className = 'p-1.5 bg-white/10 hover:bg-white/20 border border-white/20 rounded text-neutral-300 hover:text-white transition-colors text-xs font-mono min-w-[44px] h-[28px] flex items-center justify-center';
        button.textContent = 'Copy';
        button.setAttribute('aria-label', 'Copy code');

        // Copy fresh code text on click (handles highlighted spans)
        button.addEventListener('click', async () => {
          try {
            const codeText = codeElement ? codeElement.textContent : pre.textContent;
            await navigator.clipboard.writeText(codeText);
            button.textContent = '✓';
            button.style.color = '#10b981';
            setTimeout(() => {
              button.textContent = 'Copy';
              button.style.color = '';
            }, 2000);
          } catch (err) {
            console.error('Failed to copy text: ', err);
          }
        });

        buttonContainer.appendChild(button);
        pre.appendChild(buttonContainer);
      });
    }
  }, [contentHtml]);

  return (
    <div 
      ref={contentRef}
      className="prose prose-sm dark:prose-invert max-w-none
        prose-headings:text-neutral-100 prose-headings:font-bold prose-headings: tracking-tighter
        prose-h2:text-2xl
        prose-h3:text-xl
        prose-p:text-neutral-300 prose-p:leading-7 prose-p:font-base
        prose-a:text-blue-400 prose-a:no-underline hover:prose-a:underline hover:prose-a:text-blue-300
        prose-strong:text-neutral-200
        prose-code:text-neutral-200 prose-code:px-1.5 prose-code:py-0.5 prose-code:rounded prose-code:text-xs prose-code:font-mono
        prose-pre:bg-white/5 prose-pre:border prose-pre:border-white/10 prose-pre:text-neutral-300 prose-pre:relative
        prose-blockquote:border-l-blue-500 prose-blockquote:text-neutral-400 prose-blockquote:bg-white/5 prose-blockquote:px-4
        prose-hr:border-white/10
        prose-ul:text-neutral-300 prose-ul:list-disc prose-ul:ml-6 prose-ul:space-y-1
        prose-ol:text-neutral-300 prose-ol:list-decimal prose-ol:ml-6 prose-ol:space-y-1
        prose-li:text-neutral-300 prose-li:marker:text-neutral-500
        prose-table:text-neutral-300
        prose-thead:border-white/10
        prose-tr:border-white/10
        prose-th:text-neutral-200
        prose-td:text-neutral-300"
      dangerouslySetInnerHTML={{ __html: contentHtml }}
    />
  );
}

Even though we are dangerously setting the HTML content here, we won't have to worry about XSS attacks because:

The content is rendered during build time and completely controlled by me not the users.
There is no direct user input were user can just inject content and run it on the server.
There is a remark → rehype pipeline in /blog/[slug]/page.jsx that makes sure that all HTML tags are escaped and are safe for rendering

Limitations

This architecture serves my purpose fully however it does have its own limitations:

No real-time features: real-time features usually require a backend and a database support for this to work smoothly. It is definitely something that I can upgrade on in future.
Build time increases as content grows: As the number of articles increase the build time for my static site can increase alot. Until this happens I am sticking with this architecture only🤷‍♂️
No built-in analytics: I am unable to get reviews on the content of my blog as of now. This is something I will definitely add once I start getting lots of visiters daily.

Monitoring & Reliability

One thing most personal sites ignore is monitoring.

There have been times when I opened my own site and saw a 404.
Which means it could’ve been down for hours without me knowing.

So I added Uptime Robot.

Now:

My site is checked every few minutes
I get alerts if it goes down
There’s a public status page for users. You can view it here.

If the site is ever unavailable, I can redirect users to the status page instead of showing a broken site.

Final Thoughts

This blog is not just a website - it’s part of my learning system.

It helps me:

Think more clearly
Document decisions
Build a public knowledge base
Showcase how I approach engineering problems

The tech stack is simple.
The real value is owning the entire pipeline from idea → Markdown → deployed product.

And the best part?

I can nuke the whole thing tomorrow and rebuild it in an hour😂.
No lock-in. No dependencies. Just files and code.

From Full-Stack Developer to Tech Lead: Lessons I Learned the Hard Way

Osaf Ali Sayed — Tue, 28 Jul 2026 04:27:43 +0000

Stepping into a leadership role can feel surreal. When you’re early in your career, the transition from an individual contributor to a team lead is often unexpected and far more challenging than it looks from the outside.

My journey into engineering leadership began with confusion, a few painful missteps, and ultimately a powerful realization about what it truly means to own responsibility beyond just writing code.

Leadership Is Not Just Coding

I joined Ecomlytics as a full-stack developer alongside another engineer. Almost immediately, my teammate left the company. Overnight, I found myself stepping into a leadership role I hadn’t planned for.

At first, I did what felt natural: I focused harder on coding. I pushed myself to deliver features, interviewed potential hires, and casually assigned tasks to understand how others worked. In my mind, staying productive as a developer was leadership.

I was wrong.

The Wake-Up Call That Changed Everything

Things started to fall apart when my manager began asking questions like:


“When do you think this task will be completed?”

These weren’t questions about implementation details or architecture - they were about timelines, ownership, and accountability. I often didn’t have clear answers, and that resulted in missed deadlines and uncomfortable feedback.

That moment hit hard. I realized I was no longer evaluated solely on my code. I was now responsible for delivery, clarity, and team progress.

Learning to Lead Instead of Just Building

Once I accepted this shift, I consciously changed how I worked. I began embracing responsibilities I had previously avoided:

Regular and timely pull request reviews
Proactively tracking deadlines and progress
Running weekly stand-up meetings
Identifying blockers before they become problems

More importantly, I reframed how I saw my role. As a tech lead, my impact wasn’t just measured by lines of code—it was reflected in how effectively my team moved forward.

I wanted to create an environment where my teammates could rely on me, learn from me, and stay motivated. At the same time, I knew I still had a lot to learn myself.

To strike the right balance, I intentionally split my time:

50% on team and task management
50% on technical responsibilities like improving infrastructure, maintaining production systems, ensuring code quality, and reviewing pull requests

Plot Twist: Leadership Can Make You Lose Your Coding Edge

Here’s something no one warned me about - when you step into engineering leadership early, your hands-on coding skills can start to fade.

I noticed it happening. I was thinking more, typing less, and relying heavily on AI tools. While that improved productivity, it also triggered a quiet fear: Am I losing touch with real coding?

So I built a few habits to stay sharp.

1. Staying Technically Curious

I installed daily.dev and made it a habit to read about backend engineering, system design, scalability, big data, and generative AI. These are areas I actively use - or plan to use - in real production systems.

P.S originally it was only daily.dev. now it is (dev.to)[https://dev.to] as well!

2. Coding Outside of Work

To fight developer FOMO, I spend at least 30 minutes a day coding on personal projects—manually. No shortcuts. This keeps my muscle memory alive and reminds me why I fell in love with building software in the first place.

3. Getting My Hands Dirty at Work

Whenever possible, I pick up small coding tasks within my team. It helps me stay connected to the codebase and better understand the challenges my teammates face daily.

Looking back, this transition taught me that tech leadership isn’t about authority - it’s about ownership. It’s about being accountable for people, progress, and outcomes.

I feel genuinely grateful to work with a team of incredibly talented developers and to be building something that creates real business impact. The journey from full-stack developer to tech lead hasn’t been smooth - but it’s been deeply rewarding.

And this is just the beginning.

How I Made My First Contribution at Frappe

Osaf Ali Sayed — Sat, 25 Jul 2026 10:27:12 +0000

Contributing to open source has always been a goal of mine, but finding the right starting point was challenging. During my college years, despite learning development, I lacked the courage to make an open source contribution.ived valuable feedback on my pull request. My foundational knowledge of the Frappe framework and Vue.JS enabled me to implement the necessary changes smoothly.

Recently, I joined Zenduty, a startup specializing in IT Service Management. At Zenduty, we heavily utilize Python for backend development, and JavaScript, React.JS, and Vite.JS for frontend work. This experience exposed me to various technologies like Docker, Docker Compose, and GitHub Actions, significantly boosting my confidence.

Motivated by this newfound confidence, I decided to make weekly open source contributions to various platforms.

Discovering Frappe

With a strong background in Django and DRF for backend, and React for frontend, I was ready for a new challenge. While searching for open source projects, a friend introduced me to Frappe. Their organization hosts a wealth of content, including ERPNext, a Learning Management System, and Bench, a terminal tool for interconnecting everything. The interconnected nature of these projects fascinated me.

Frappe primarily uses Python for backend development and their own Frappe framework, with Vue.JS for frontend. This meant I needed to familiarize myself with their framework before contributing. I began by exploring the "good first issues" in their repository and found a task to create a related courses component. A previous attempt at this task had been made but was incomplete.

Diving into Frappe and Vue.JS

I embarked on understanding how the Frappe backend operates and how Vue.JS differs from React.JS, particularly in component loading. Frappe's approach to database models and API requests is distinct from Django, with migrations managed through Bench.

With guidance from Jannat Patel, a product engineer at Frappe, I received valuable feedback on my pull request. My foundational knowledge of the Frappe framework and Vue.JS enabled me to implement the necessary changes smoothly.

Looking Ahead

I am now focused on submitting more pull requests to Frappe. My ultimate goal is to propose a feature for their Learning Management System. Achieving this would not only be a personal milestone but also contribute to a project that benefits others.

For those of you who are interested in the PR and the related issue you can find it here.

I Built My Own Load Balancer In Python Without AI

Osaf Ali Sayed — Thu, 23 Jul 2026 06:35:56 +0000

In the age of AI, nothing is black and white anymore.

Everyone on the internet has an opinion, and everyone shares it. AI is going to take your job. No, AI won't take your job. Junior roles are done for, but senior engineers are exactly who companies will fight over. Pick any thread on any given day and you'll find all of these being argued at once, usually with equal confidence.

This is my website, so here's mine.

I think the age of AI is great. We ship fast. We build faster. But the part I keep coming back to is this: it's the one skilled developer who's quietly making absurd money right now. The developer who persisted, who has years of real experience, who can craft a production-ready system before writing a line — that person just got a 4x multiplier on their output. AI didn't replace them. It handed them a bigger lever.

Which is slightly uncomfortable, because it means the moat isn't the typing. It's the judgment. And judgment is the one thing you can't prompt your way into overnight.

So I decided to do something about it.

The problem with letting AI drive

When you let AI write everything, something quiet happens. You stop making the small decisions. You stop feeling the friction of "wait, how should these two things talk to each other?" You get output, skim it, accept it, move on. It works. It ships. And your own architectural muscle goes soft without you noticing.

I didn't want to wake up in five years and find out I'm a vibe coder.

So I picked something I've read about a hundred times in system design material but had never built with my own hands: a load balancer.

Do we need to write our own? No. Should you run a hand-rolled one in production? Absolutely not — use nginx, HAProxy, or whatever your cloud hands you. But should you build one for learning? A hundred percent. It's small enough to finish and deep enough to teach you something real about how traffic actually gets spread across servers.

Why Python, of all things

I wrote this in Python mostly because I knew nobody writes a load balancer in Python. 😂 I found a repo and an article walking through one in Go, and Go is arguably the "correct" choice here. But I didn't want correct. I wanted to spin something up in a language I'm comfortable in so the language never got in the way of the thinking. The whole point was to wrestle with the ideas, not fight a borrowed syntax I'd have to look up every ten seconds.

The rules I set for myself

To make this worth anything, I set two ground rules and stuck to them.

No AI anywhere in the actual code. No matter how ugly it got, no matter how badly I wanted to just ask, I wrote every line by hand. I gave it five hours a week. Honestly, I think every freelancer and every developer in their growth phase should carve out five hours a week for their core skill — no client work, no shortcuts, just you and the fundamentals.

Google and AI are for lookups only. If I forget the exact syntax for, say, a class-level variable versus an instance one in Python, I'm allowed to look it up. That's just remembering vocabulary. What I'm not allowed to do is ask for architecture, logic, or "how should I structure this." The thinking has to be mine. The syntax can come from anywhere.

That line between looking up a word and outsourcing the thinking turned out to be the whole point of the exercise.

Scope of the project

For this project I did not want to implement something crazy and I wanted to wrap things up in 5 hours of coding session. So I limited the goals for this project:

A simple load balancer. It should be able to balance the load between the server using an algorithm in this case it will be round robin algorithm. we can replace such things into separate files later on to add more algorithms but that is out of scope for today's session.
Health Checks. One day you are sleeping and you realize that a server is down oh no! oh my god! what to do now! and you are using Osaf Ali Sayed's very own production-ready load balancer. nobody would want their load balancer to crash just because a server crashed do they?🙂 We need to make sure if a server goes down, our load balancer can detect it and handle it properly. for this we will write a thread which will run along side the load balancer, it will keep checking the /health endpoint on all the servers. if a server is down we do not send request to that server.
Server Death Checks. If by chance we hit the server before the health check was able to mark it dead. we need to detect this during the request to make the system more robust. Ideally here we would redirect to another server if request failed but for now this is out of scope.

What actually happened

It took me five hours. I wrote 200 lines of code. That's it.

And it was an eye-opener.

There's a specific feeling you get when you build something entirely yourself, where you understand every line because you had to fight for it. I hadn't felt that in a while. Somewhere in the AI-assisted daily grind, I'd traded it away for speed without realizing I'd made the trade.

For the balancing, I went with round robin the simplest, most classic load-balancing algorithm there is. You keep a list of your backend servers, and each incoming request goes to the next server in line, cycling back to the start when you reach the end. Request one to server A, request two to B, request three to C, request four back to A. No weights, no cleverness. Just fair, even rotation.

Here's the round-robin selection:

class ProxyHandler(BaseHTTPRequestHandler):

    counter = 0
    lock = threading.Lock()
    server_state = [True for i in servers]

    # ... inside do_GET, under the lock ...
    with ProxyHandler.lock:
        checked = 0
        while True:
            if checked == len(servers):
                # every server is dead
                self.send_response(502)
                self.end_headers()
                self.wfile.write(b'{"error":"all servers are dead"}')
                return

            ProxyHandler.counter = (ProxyHandler.counter + 1) % len(servers)
            if ProxyHandler.server_state[ProxyHandler.counter]:
                choosen_index = ProxyHandler.counter
                break

            checked += 1

        server_url = servers[choosen_index]

Then a server died, and things got interesting

Plain round robin has an obvious flaw: it doesn't know or care whether a server is actually alive. If server B falls over, round robin will happily keep sending it every third request, and every one of those requests just dies.

So I added health checks.

The idea is simple. A background thread runs on a loop, and every few seconds it pings a /health endpoint on each backend. If a server answers with a 200, it's marked alive. If it refuses the connection or answers with anything else, it gets marked dead. The router then skips any server currently marked dead when it's picking where to send the next request.

The nice part is that this cuts both ways. A server going down isn't a permanent death sentence. The health-check loop keeps pinging it anyway, so the moment it comes back up and answers a 200 again, it gets flipped back to alive and starts receiving traffic like nothing happened. No restart, no manual intervention. The balancer just notices and adjusts.

Here's the health-check loop:

def health_check_loop():
    while True:
        for i, backend in enumerate(servers):
            host, port = backend.split(":")
            outgoing_headers = {'Host': backend}

            try:
                conn = http.client.HTTPConnection(host, int(port))
                conn.request("GET", '/health', headers=outgoing_headers)
                resp = conn.getresponse()

                if resp.status == 200:
                    ProxyHandler.server_state[i] = True
                else:
                    ProxyHandler.server_state[i] = False

            except ConnectionRefusedError:
                ProxyHandler.server_state[i] = False

        time.sleep(5)


# started as a background daemon thread so it runs alongside the server
t = threading.Thread(target=health_check_loop, daemon=True)
t.start()

And the request handler that picks a live server and forwards the request:

def do_GET(self):
    path = self.path
    headers = self.headers
    outgoing_headers = dict(headers)

    # only the tiny critical section is locked: read + bump the shared
    # counter and pick a live server. everything slow stays outside.
    with ProxyHandler.lock:
        checked = 0
        while True:
            if checked == len(servers):
                self.send_response(502)
                self.end_headers()
                self.wfile.write(b'{"error":"all servers are dead"}')
                return

            ProxyHandler.counter = (ProxyHandler.counter + 1) % len(servers)
            if ProxyHandler.server_state[ProxyHandler.counter]:
                choosen_index = ProxyHandler.counter
                break

            checked += 1

        server_url = servers[choosen_index]

    host, port = server_url.split(":")
    outgoing_headers['Host'] = server_url
    outgoing_headers['X-Forwarded-For'] = self.client_address[0]

    # forwarding happens outside the lock, so requests run in parallel
    try:
        conn = http.client.HTTPConnection(host, int(port))
        conn.request("GET", self.path, headers=outgoing_headers)
        resp = conn.getresponse()

        status = resp.status
        body = resp.read()

        self.send_response(status)
        self.end_headers()
        self.wfile.write(body)

    except ConnectionRefusedError:
        # server died mid-request: mark it dead and report failure
        ProxyHandler.server_state[choosen_index] = False
        self.send_response(503)
        self.end_headers()
        self.wfile.write(b'{"error":"this server is dead!"}')


server = ThreadingHTTPServer(('127.0.0.1', 8080), ProxyHandler)
server.serve_forever()

There's also a nice fallback baked in: if the handler walks the whole list and every server is marked dead, it doesn't just hang or crash. It returns a 502 saying all servers are down. And if a request gets routed to a server that dies right at that moment, the handler catches the refused connection, marks that server dead on the spot, and returns a 503 instead of silently failing.

The part that genuinely humbled me: threading

Here's what I did not expect to be the hard part. Threading is brutal to reason about.

A load balancer has to handle multiple requests at once, that's the entire job. So it's inherently concurrent, which means multiple threads are touching the same shared counter that tracks whose turn it is. And the second you have multiple threads reading and writing the same variable, you're one bad interleaving away from two requests grabbing the same "next" server, or the counter skipping, or worse.

This is the thing we all studied in college and mostly nodded along to: the race condition. It's very different to actually hit one in code you wrote yourself.

The fix is a lock. But the real lesson wasn't that I needed a lock, it was where. My first instinct was to wrap everything in the lock and move on. That "works," but it's stupid: it makes the whole thing synchronous. One request at a time. You've just built a load balancer that can't handle load, which defeats the entire purpose.

So I had to actually think about it. I ended up repositioning my code so the lock only wraps the tiny critical section, the part that reads and bumps the shared counter and picks the index. Everything else, the slow part, the actual forwarding of the request to the backend, happens outside the lock, so requests can genuinely run in parallel. Getting that boundary right meant understanding the context of my own code: which few lines truly can't be touched by two threads at once, and which lines are fine to run concurrently.

That was the moment the whole exercise paid for itself. Not the load balancer. The forced understanding of exactly where concurrency bites.

AI is a lever. A huge one. But a lever does nothing without someone who knows where to put it. The developers who'll thrive aren't the ones who prompt the fastest they're the ones who still understand the machine well enough to catch it when it's wrong.

So build the small thing by hand. Kill the autocomplete for a few hours. Feel the friction on purpose. Five hours a week is nothing against a career, and it's the cheapest insurance you can buy against becoming a vibe coder.

Here is the github repo if you want to see one file pulled together: github.com/OsafAliSayed/load-balancer