Backend systems that don't page you at 3 a.m.
I design and ship production-grade APIs with ASP.NET Core — Clean Architecture, CQRS, and PostgreSQL underneath, so the parts nobody sees are the parts that hold.
Five services needed the same event. I stopped making them ask each other.
For the LMS microservices platform, I studied Kafka to move events — enrollments, grade updates, notifications — through a distributed log instead of chaining synchronous HTTP calls between every service that needed to react.
- Producers publish once; every interested service consumes independently, with no direct dependency between them
- Topics split into partitions so throughput scales horizontally across brokers
- Consumer groups let multiple instances of a service share the load without processing the same message twice
- Confluent's .NET client wires Kafka producers and consumers directly into ASP.NET Core services
- Docker Compose ran the broker and every service locally, close to how it would actually deploy
I can bring the same pattern into any backend where synchronous calls are the bottleneck — decoupling grading, notifications, or analytics from the request that triggers them, and integrating message queues wherever a microservice architecture needs the efficiency.
"I'd rather spend two extra days understanding why a pattern exists than a week debugging code I copied without knowing."Zeyad — on learning systems the slow way
Built for production, not for the demo.
Three things I refuse to skip, on every backend I ship — regardless of the deadline.
Data that stays correct
Dapper on the hot read paths, EF Core for writes, and cursor-free pagination via
COUNT(*) OVER() so a page count never costs a second query.
Auth you don't babysit
JWT access tokens, rotating refresh tokens, replay detection, rate limiting and lockout — the boring parts that prevent the interesting incidents.
Work off the request path
Hangfire handles email delivery, token cleanup and scheduled sweeps in the background, so the API responds in milliseconds — not while an SMTP call blocks the thread.
InvoiceBuilder — the flagship backend
A production-shaped invoicing API, built the way I'd build one for a paying client: layered, tested, and instrumented from day one.
- ArchitectureClean Architecture + CQRS via MediatR
- AuthJWT · refresh rotation · theft detection
- ReadsDapper + window-function pagination
- Background jobsHangfire — email, cleanup, sweeps
- TestingxUnit · Moq · FluentAssertions
- InfraDockerized API + PostgreSQL
"A backend that only works in the demo isn't done. Tests, rate limits and background jobs are the parts nobody notices — until they're missing."Zeyad — on shipping
Built by someone still in the classroom — and already in production.
Final-year CS & AI student who spends less time on assignments and more time on things that have to actually stay up. I learn systems by taking them apart, not by watching a tutorial about them.
A few things I've shipped or am shipping.
InvoiceBuilder
A Clean Architecture invoicing API with rotating JWT auth, Dapper-backed pagination, and a full xUnit test suite for the auth handlers.
View repo ↗Muhasaba
A daily habit dashboard for Muslim men — salah, qiyam, deep work, sleep — with a gamified level system, from validation to build.
View repo ↗LMS Microservices Platform
A microservices-based learning platform built with a six-person team — Kafka for inter-service messaging, Docker Compose for orchestration, and independently deployable services.
View repo ↗Have a backend problem worth solving properly?
Open to backend roles at product & SaaS companies, and contract work on the side.