Skip to main content
01 / PORTFOLIO NOTEBOOKGIZA, EGYPT · CAIRO UNIVERSITY '27

YOUSSEF HOSSAM
BACKEND SOFTWARE ENGINEER

"I build backend systems that stay correct when things get messy."

C#/.NET backend engineer focused on APIs, distributed systems, messaging, concurrency and reliable application architecture.

HOW A REQUEST MOVESREQUEST → STATE → EVENT
SYNCHRONOUS WRITE PIPELINE
CLIENT
API
DOMAIN
DATABASE
ASYNCHRONOUS DISPATCH
OUTBOX (EVENT STORE)
MESSAGE BUS (RABBITMQ)
CONSUMERS (INBOX)
02 INTERNSHIPSLink Development & Innovitics
C# & .NET 9DDD · CQRS · Event-Driven
CAIRO UNIV. '27B.Sc. in Computer Science
PRODUCTIONDirect Code in Live Systems
02 / SELECTED SYSTEMS

CASE STUDIES

TWO PROJECTS THAT SHOW HOW I APPROACH BACKEND SYSTEMS

PROJECT 01 // MODULAR MONOLITHLAST-MILE LOGISTICS

DELIVERY WITHOUT DROPPED EVENTS.

A production-oriented last-mile delivery platform built as a modular monolith with five independently structured modules.

5 BOUNDED CONTEXTS TOPOLOGYTRANSACTIONAL OUTBOX / INBOX
01 / MODULE
ORDERS

Order lifecycle and outbox event registration.

02 / MODULE
DRIVERS

Driver availability and synchronous gRPC contracts.

03 / MODULE
DISPATCHING

Internal assignment coordination with drivers.

04 / MODULE
TRACKING

Delivery progression and location updates.

05 / MODULE
NOTIFICATIONS

Deduplicated consumer inbox for status alerts.

[MODULES ↕ RABBITMQ / MASSTRANSIT]INTERNAL COMMUNICATION: DRIVERS ↔ gRPC ↔ DISPATCHING[OUTBOX / INBOX RELIABILITY]
THE PROBLEM

When asynchronous parts of a system communicate, failures can happen between changing application state and publishing the event that describes that change.

THE APPROACH

Transactional Outbox and Inbox patterns help keep state changes and message processing reliable while protecting consumers from duplicate message handling.

.NET 9C#DDDCLEAN ARCHITECTUREMODULAR MONOLITHRABBITMQMASSTRANSITGRPCPROTOCOL BUFFERSPOSTGRESQLDOCKER
PROJECT 02 // CONCURRENCY & CQRSCHECKOUT & IDEMPOTENCY

SAFE EVEN WHEN THE REQUEST REPEATS.

An e-commerce backend designed around checkout, payments, inventory workflows and safe handling of repeated operations.

IDEMPOTENCY EXECUTION FLOWREQUEST → IDEMPOTENCY KEY CHECK
PATH 01 // FIRST RUN
REQUEST INCOMINGKEY SUPPLIED
OPERATION PROCESSED?NO
PROCESS OPERATIONDOMAIN LOGIC
SAVE RESULTRECORDED
PATH 02 // REPEATED PASS
RETRY / DUPLICATE WEBHOOKSAME KEY
OPERATION PROCESSED?YES
DO NOT REPEAT SIDE EFFECTSHORT-CIRCUIT
RETURN SAFE RESULTSTORED RESPONSE
THE PROBLEM

Checkout and payment workflows receive retried commands and duplicate webhooks when networks fail or clients retry.

THE APPROACH

Idempotency keys ensure operations process once; subsequent requests safely return the stored result without re-triggering side effects.

ASP.NET COREEF CORECLEAN ARCHITECTUREDDDCQRSMEDIATRJWTREDIS
ARCHITECTURAL SIGNATURE // DEFENSIVE DESIGNHAPPY PATH VS. REAL CONDITIONS
CORE PREMISE

SOFTWARE CANNOT ASSUME PERFECT CONDITIONS.

Most backend code assumes the network never drops, users click once, and dependencies always reply in time. In real production, failures happen midway.

THE GOAL: KEEP STATE CORRECT WHEN REQUESTS FAIL OR REPEAT.
HAPPY PATHIDEAL FLOW
REQUESTPROCESSCOMMITRESPONSE
MESSY PATHREAL WORLD CONDITIONS
REQUESTTIMEOUTRETRYDUPLICATE?
FINAL OUTCOME:SYSTEM STILL CORRECT.
03 / EXPERIENCE

PRODUCTION TRACK RECORD

COMMERCIAL WORK WITH REAL SYSTEM CONSEQUENCES

  1. LINK DEVELOPMENT

    .NET BACKEND DEVELOPER INTERN

    Worked on a live production application, implementing a complete cart feature across backend APIs and frontend integration, integrating workflows with CRM systems and debugging an existing production codebase.

    • .NET
    • UMBRACO
    • RABBITMQ
    • SQL SERVER
  2. INNOVITICS

    .NET BACKEND DEVELOPER INTERN

    Built REST APIs for meeting-room booking and employee vacation workflows, including authentication, authorization, concurrency-safe booking, notifications and cloud integrations.

    • ASP.NET CORE
    • MYSQL
    • AZURE AD
    • FIREBASE
    • AZURE
04 / PRINCIPLES

HOW I THINK

ENGINEERING MENTAL MODELS FOR UNSTABLE ENVIRONMENTS

  1. MODEL THE DOMAIN FIRST.

    Business rules should live where they belong, not inside controllers.

  2. DESIGN FOR RETRIES.

    Networks fail. Messages repeat. Users click twice. A system must safely handle repeated operations.

  3. MAKE BOUNDARIES EXPLICIT.

    A module should have a clear responsibility and a clear contract. No leaking private domain state across contexts.

  4. TEST MORE THAN THE HAPPY PATH.

    Correctness becomes more important when conditions stop being ideal. Validate boundary violations, duplicate inputs, and failure recovery.

05 / CAPABILITIES

TOOLBOX

TECHNICAL FOUNDATION · NO ARBITRARY PERCENTAGES

01 // RUNTIME
BACKEND
C# · ASP.NET Core · EF Core · Dapper · SignalR · REST APIs
02 // DESIGN
ARCHITECTURE
Clean Architecture · DDD · CQRS · Modular Monolith · SOLID · Dependency Injection
03 // DISTRIBUTED
MESSAGING & SYSTEMS
RabbitMQ · MassTransit · gRPC · Protocol Buffers · Transactional Outbox · Inbox Pattern · Idempotency
04 // STORAGE
DATA
SQL Server · PostgreSQL · MySQL · MongoDB · Redis
05 // SECURITY
IDENTITY
JWT · OAuth 2.0 · OpenID Connect · OpenIddict · ASP.NET Identity
06 // INFRASTRUCTURE
CLOUD & DELIVERY
Azure · Azure Blob Storage · Docker · GitHub Actions · Swagger / OpenAPI
07 // QUALITY
TESTING
xUnit · Integration Testing · Architecture Testing
08 // INTELLIGENCE
AI / GENAI
LLM APIs · RAG · Embeddings · Vector Databases
06 / PROFILEBACKGROUND & INTENT

"I LIKE THE PART OF SOFTWARE YOU DON'T SEE."

I’m Youssef Hossam, a Computer Science student at Cairo University and a backend engineer focused on .NET and distributed systems.

I enjoy problems around concurrency, messaging, authentication, data consistency and system boundaries.

Through internships at Link Development and Innovitics, I’ve worked with production applications and collaborated across backend, frontend, mobile and QA teams.

I’m especially interested in building backend software that remains reliable and understandable as it grows.