Projects |

Nginx Load Balancer & Reverse Proxy

Fri, 10 Apr 2026 00:00:00 +0000

A hands-on deep-dive into how production traffic actually gets distributed — built from scratch using Nginx as a reverse proxy in front of three Dockerized Node.js app instances.

Overview

The goal was to understand load balancing not just in theory but by building and operating it. The result is a fully containerized system where Nginx round-robins incoming HTTPS requests across three identical Node.js instances, each running in its own Docker container — with health checks, SSL termination, and a live dashboard that makes the load balancing visible in real time.

Approach

Each app instance is a lightweight Express server, containerized with Docker and orchestrated via Docker Compose. Nginx sits in front of all three, handling SSL termination and distributing requests using round-robin by default.

Key areas explored:

Reverse proxying — configuring Nginx to forward requests to upstream containers by service name over Docker’s internal network
Load balancing algorithms — round-robin as the default, with awareness of alternatives like least_conn and ip_hash
SSL/TLS — terminating HTTPS at the Nginx layer so upstream apps only deal with plain HTTP internally
Docker health checks — using wget to probe each container’s /health endpoint, with configurable interval, timeout, retries, and start period
Container networking — understanding the difference between host-mapped ports and internal container ports, and why health checks use port 3000 not 3001/3002/3003
Server-side templating — injecting the APP_NAME environment variable into HTML at request time so the dashboard shows which instance is serving

Architecture

[Client / Browser]
 ↓
 [Nginx :443] ← SSL termination + round-robin
 / | \
App1 App2 App3 ← Node.js containers on internal port 3000
:3001 :3002 :3003 ← host-mapped for direct debug access

Each reload through Nginx cycles to the next upstream instance — visible live on the dashboard.

Health Check Setup

Every container runs a health check via Docker Compose:

healthcheck:
 test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
 interval: 30s
 timeout: 5s
 retries: 3
 start_period: 10s

The /health endpoint on each app logs every probe hit in memory, which the frontend fetches every 15 seconds via /api/info to populate the live request log.

Tech Stack

Reverse Proxy: Nginx 1.28
App Runtime: Node.js 20 (Alpine)
Framework: Express
Containerization: Docker + Docker Compose
Security: SSL/TLS with certificate termination at Nginx
OS: Windows + Docker Desktop

Key Takeaways

Building this made abstract networking concepts concrete. Understanding why a health check uses port 3000 instead of 3001, why __APP_NAME__ needs server-side injection rather than client-side JS, and why a self-signed cert behaves inconsistently across round-robin rotations — these are the kinds of details that only surface when you actually operate the system yourself.

Personal Portfolio Website

Wed, 01 Apr 2026 00:00:00 +0000

A personal portfolio site built from scratch — and a hands-on introduction to the modern developer workflow, from static site generation to automated deployment.

Overview

The goal was simple: have a live portfolio to showcase projects. The outcome was something more valuable — a practical understanding of how modern deployment pipelines actually work, gained by building one myself.

Approach

The stack centres on Hugo as the static site generator, with HugoBlox for theming and layout configuration. Content is written in Markdown with YAML front matter, and every push to the main branch triggers an automated deployment via GitHub Actions to GitHub Pages.

Key learning areas:

YAML — understanding the syntax, structure, and role of .yml files in configuring GitHub Actions workflows
Markdown customisation — using front matter to configure pages, projects, and metadata within a static site generator
GitHub Actions — writing and reading CI/CD workflows that automate build and deploy steps
Linux environment — setting up and managing the entire development workflow on Arch Linux for the first time

Architecture

[Push to main] → [GitHub Actions Trigger]
 ↓
 [Hugo Build Step]
 ↓
 [Deploy to GitHub Pages]

Every commit kicks off the full build-and-deploy cycle automatically — no manual steps.

Tech Stack

Static Site Generator: Hugo + HugoBlox
Deployment: GitHub Pages
Automation: GitHub Actions
Configuration: YAML, Markdown
Environment: Arch Linux

Key Takeaways

Sometimes the side-quests are the real learning. Setting up this portfolio introduced version-controlled deployments, declarative configuration, and Linux-native development workflows — all in the context of a project that was genuinely mine to own end to end.

RESTful Task Management API

Sun, 01 Mar 2026 00:00:00 +0000

A robust backend API for a task management application, designed around clean REST architecture and built to integrate seamlessly with any modern frontend.

Overview

The goal was to build a backend that any frontend — web or mobile — could consume without friction. That means consistent response shapes, clear error messages, and a database schema that won’t need restructuring as the app scales.

Key features

Full CRUD — complete HTTP method coverage for task resource lifecycle management
Optimised schema — PostgreSQL with normalisation and integrity constraints from the start
Standardised JSON — consistent response structure across all endpoints, including errors
Clean code — leverages Laravel 12 and PHP 8.4 features for concise, maintainable logic

Architecture

Client (Web/Mobile)
 │
 ▼
Laravel 12 Routes
 │
 ▼
Controllers → Form Requests (validation)
 │
 ▼
Eloquent Models
 │
 ▼
PostgreSQL

Tech stack

Backend

Laravel 12 (PHP 8.4)
PostgreSQL (migrations, constraints, normalisation)
Composer

Tooling

Postman (endpoint testing & documentation)

Key takeaways

This project deepened my understanding of API design — particularly around response consistency, error handling, and building backends that are easy to consume regardless of the frontend technology used.

Pipeline Optimisation with Operations Research

Mon, 01 Dec 2025 00:00:00 +0000

An operations research project that treats a real-world DevOps pipeline as a scheduling problem — applying classical OR methods to reduce deployment time for a critical banking application.

Overview

CI/CD pipelines in high-stakes environments like banking have strict reliability and performance requirements. The challenge was to model the pipeline mathematically and find the minimum possible deployment duration while respecting task dependencies and enabling parallelism where possible.

Approach

The pipeline was modelled as a directed acyclic graph (DAG) where each node is a pipeline stage and edges represent precedence constraints.

Methods applied:

Kahn’s topological sort — to establish a valid execution order
PERT/CPM — to compute earliest and latest start dates for each task
Critical path analysis — to identify zero-slack tasks that directly determine total duration
Slack analysis — to find where parallelisation opportunities exist

Results

Critical path: 64 minutes — the theoretical minimum for a full deployment cycle
Identified which pipeline stages offered the most optimisation potential
Produced concrete managerial recommendations for resource prioritisation and risk mitigation

Architecture diagram

[Checkout] → [Build] → [Unit Tests] ─────────────────────────┐
 ↘ ▼
 [Integration Tests] → [Security Scan] → [Deploy]
 ↗
 [Docker Build] ──────

Stages on the critical path have zero slack — any delay directly increases total deployment time.

Tech stack

Language: Python
Methods: PERT/CPM, topological sort (Kahn’s algorithm), critical path analysis, graph theory

Key takeaways

Operations research techniques that seem purely theoretical deliver actionable insights in modern software engineering — especially where reliability and time-to-market are critical. This project changed how I think about pipeline design.

Advanced Algorithms & Data Structures

Sat, 01 Nov 2025 00:00:00 +0000

A series of algorithm implementations focused on understanding performance trade-offs through experimental analysis. Rather than relying on theoretical Big-O alone, every implementation is benchmarked and visualised against real data.

Sorting & search complexity

Seven sorting algorithms benchmarked across four data distributions — random, ascending, descending, and identical values:

Algorithm	Complexity	Best case
Quick sort (dual-pivot)	O(n log n) avg	Random data
Merge sort	O(n log n)	Consistent
Heap sort	O(n log n)	Consistent
Insertion sort	O(n²)	Nearly-sorted data
Selection sort	O(n²)	—
Bubble sort	O(n²)	—
Binary search	O(log n)	—

Runtime was normalised against T(n)/n, T(n)/(n log n), and T(n)/n² to empirically verify complexity classes. Key finding: insertion sort consistently outperforms O(n log n) algorithms on nearly-sorted data — a result that only becomes intuitive when you see it in a plot.

Hash tables

Chaining with linked lists for collision handling
Open addressing: linear probing, quadratic probing, double hashing
Benchmarked on datasets up to 100,000 elements — collision rates and lookup times compared across all strategies

Probabilistic filters

Bloom filter with k = 2, 3, 4 hash functions — false positive rate vs. memory trade-off
Count-Min Sketch for frequency estimation — precision vs. hash function count

String pattern matching

Naïve search vs. deterministic finite automaton (DFA) — transition function computation and pattern recognition on randomly generated text
Performance comparison shows DFA’s advantage grows with text length

Dynamic programming

Fibonacci: naïve recursion vs. memoisation — exponential-to-linear improvement demonstrated empirically
Coin change: minimum coin count with full optimal solution reconstruction

Tech stack

Language: Python
Libraries: Matplotlib, NumPy
Focus: Algorithm design, complexity analysis, experimental benchmarking

COVID-19 Epidemic Modelling (SIRD)

Sat, 01 Mar 2025 00:00:00 +0000

An epidemiological modelling project simulating the spread of COVID-19 in Morocco using the SIRD compartmental model — applied mathematics meeting a real-world public health problem.

The model

The SIRD model divides a population into four compartments evolving over time:

Compartment	Meaning
S	Susceptible — not yet infected
I	Infected — currently infectious
R	Recovered
D	Deceased

The dynamics are governed by a system of ordinary differential equations:

dS/dt = -β·S·I/N
dI/dt = β·S·I/N - γ·I - μ·I
dR/dt = γ·I
dD/dt = μ·I

Where β is the transmission rate, γ the recovery rate, and μ the mortality rate.

My contribution

Analysed and implemented the SIRD ODE system
Solved numerically using SciPy to simulate population evolution over time
Tuned β, γ, and μ parameters against observed Moroccan COVID-19 data
Visualised S, I, R, D curves and interpreted dynamics — peak infection timing, convergence behaviour, and sensitivity to β changes

Key finding

A small change in the transmission rate β shifts the infection peak by weeks — a concrete illustration of why epidemic modelling matters for policy decisions, and why early intervention has outsized impact.

Tech stack

Language: Python
Libraries: NumPy, SciPy (ODE solving), Matplotlib (visualisation)
Focus: Applied mathematics, numerical methods, data visualisation