Dependable APIs, trustworthy data flows, and cloud delivery designed for real-world use.
I’m Mohamed Baghdad, a software engineer focused on dependable APIs, data integrity, deployment pipelines, and the operational details that keep services useful after launch.
A shortlist from my GitHub, selected for backend depth, deployment thinking, and evidence of real operational decisions.
A Java 21 loyalty platform API built around safe points transactions. The service combines Firebase authentication with role-aware endpoints, idempotency controls, per-user rate limits, scheduled cleanup, audit trails, and operational metrics.
A full-stack point-of-sale system with a server-only database boundary. One build targets local Docker, Render, or Vercel while Neon PostgreSQL remains the source of truth and store-level configuration stays in the environment.
A team-built Android safety engine for food, cosmetics, and medication. It queries multiple product sources concurrently, selects the strongest result, normalizes ingredient data, and evaluates it against a user’s saved allergy profile.
A mobile-first learning platform built as a pragmatic modular monolith. Android and React clients share one Spring Boot backend for identity, courses, enrollments, progress, server-scored exams, analytics, and certificates.
An architecture-first lab for IoT telemetry and streaming analytics. Kafka connects ingestion and processing; PostgreSQL and Redis handle durable and fast data paths; Prometheus, Grafana, and exporters make the local platform observable.
I work across the parts of a backend that determine whether it remains understandable, deployable, and safe under imperfect conditions.
Clear contracts, validation, authentication, authorization, rate policies, idempotent commands, and consistent error models.
Relational modeling and transactional flows first; document databases and caches where their access patterns earn the complexity.
Environment-safe configuration, containerized builds, health checks, automated workflows, and deployment blueprints.
Metrics, health endpoints, audit context, bounded jobs, and architecture documentation that make behavior visible.
A useful system is not only one that works once. It has to survive retries, explain failures, and leave the next engineer a map.
Timeouts, repeated commands, and partial state are design inputs. Idempotency and explicit error handling belong in the first version.
Health checks and metrics turn runtime questions into answers.
Architecture decision records, deployment notes, and operational limits keep a codebase legible when context changes.
I’m a software engineering student at EMSI and an ALX-trained backend engineer. I use coursework, client work, and independent systems labs to turn architecture ideas into working services.