Mubarak Elagib

Mubarak Elagib

Senior Integration Engineer · .NET & Azure

in production · 400+ branches · 12+ partners

The space between systems

Integration Architecture
Built for Production. Ready for AI.

I design and build Azure-native enterprise integration platforms connecting ERP systems, marketplaces, payment providers, loyalty programs, and business services through resilient, event-driven architectures.

These platforms support mission-critical retail operations across 400+ branches and 12+ partners. My current focus is extending them with Agentic AI systems that can reason, orchestrate tools, and operate on live enterprise data.

View Case StudiesGet in TouchDownload Resume
Azure FunctionsService BusAzure SQL.NETC#Agentic AI

400+

Branches Connected

40%

Reduction in Manual Order Handling

60%

Faster Partner Onboarding

12+

Partner & Platform Integrations

10+

Years of Experience

Career Journey

From developer to architect.

A decade across government, banking, energy, and retail has shaped one conviction: the most valuable systems are the ones connecting everything else.

  1. Sep 2023 — Present

    Retail & E-CommerceCurrent

    Senior Integration Engineer · Integration Architect

    Abdullah Al-Othaim Markets · Riyadh, Saudi Arabia

    Architecting the Azure-native integration platform connecting 400+ branches with 12+ marketplace, payment, and loyalty partners — now extended into production Agentic AI.

  2. Jun 2022 — Aug 2023

    Energy

    Senior Software Engineer — Backend & Architecture

    SITE — Saudi Ministry of Energy · Riyadh, Saudi Arabia

    Led backend architecture for the Energy Information Center Platform using ASP.NET Core, Clean Architecture, and Domain-Driven Design.

  3. Feb 2020 — Mar 2022

    Banking

    Senior .NET Full-Stack Developer — Banking Systems

    Omdurman National Bank · Khartoum, Sudan

    Modernized critical banking applications from .NET Framework to .NET Core and built secure REST/SOAP integrations with external partners.

  4. Jan 2017 — Jan 2020

    Government

    Full-Stack .NET Developer — Government Systems

    National Information Center (NIC) · Khartoum, Sudan

    Built and maintained enterprise government applications across multiple national systems, from solution design to production support.

  5. Apr 2014 — Apr 2016

    Academia

    Teaching Assistant — Computer Science

    Gedarif University · Gedarif, Sudan

    Taught C#, OOP, data structures, and software engineering fundamentals — where the habit of sharing knowledge began.

End-to-End Ownership

I own the platform — not just the integration code.

From architecture and implementation to deployment, data, observability, and production support, I take responsibility for the complete integration lifecycle.

Architecture

System design · contracts · integration patterns

Engineering

.NET · Azure Functions · Service Bus · APIs

Data

Azure SQL · schemas · stored procedures · performance

Delivery

CI/CD · environments · infrastructure · releases

Operations

Monitoring · incident response · reliability · optimization

Case Studies

Here's what I've built.

Real-world integration platforms I designed and led — with architecture diagrams, key decisions, and measurable outcomes.

● trace_id: mp-ord-7f2a41 · hops: sqs → lambda → sbus → func → sql · status: 200 · retries: 0

Unified Marketplace Integration Platform

Flagship
Event-DrivenCross-Cloud (AWS → Azure)Serverless-FirstBidirectional Sync

The Problem

Extending internal systems (ERP, POS, inventory) to support marketplace channels required building a multi-platform integration layer connecting with Amazon, Noon, HungerStation, Jahez, AliExpress, and Trendyol. Each platform operates with different API standards, authentication models, rate limits, and data contracts. Even within a single platform, multiple integration models exist — for example, Amazon Marketplace, FBA, and invoice/report flows — each with distinct workflows, data structures, and operational constraints. The solution focused on designing scalable, event-driven pipelines that handle high volumes of orders and transactions, support near real-time inventory and pricing synchronization, enable reliable bidirectional data flows, and maintain consistency between internal and external systems across all channels.

Architecture diagram

Key Design Decisions

  • Amazon's mandatory AWS infrastructure (SQS, Lambda, S3) required a cross-cloud bridge. Event-driven consumption via Lambda → Azure Service Bus kept the Azure pipeline consistent across all three Amazon models (Marketplace, FBA, reports) without polling or tight coupling to AWS internals.
  • Service Bus as the integration backbone across all channels — decoupling external producers from internal consumers, enabling per-channel throughput control, message replay on failure, and protection against upstream rate limit spikes.
  • Transformation and normalization layer before any internal write — each marketplace payload maps to a canonical internal schema with idempotency checks, preventing duplicate processing under retries, redelivery, or throttle-driven backoff.

How It Works

Amazon KSA runs three independent integration models: Marketplace and FBA orders are ingested via Lambda functions consuming from SQS, forwarded to Azure Service Bus, processed by Azure Functions (.NET 8), and persisted to Azure SQL. Invoice and report flows use a separate pipeline with S3 as the data source. Noon, HungerStation, Jahez, AliExpress, and Trendyol each run dedicated Azure-native bidirectional pipelines — inbound order ingestion and outbound inventory/pricing feeds — built on the same Service Bus and Azure Functions pattern. All pipelines include rate limit handling, retry with backoff, and structured logging with correlation IDs.

Impact

7 marketplace channels integrated, including 3 distinct Amazon fulfillment models
Bidirectional sync: inbound orders + outbound inventory/pricing feeds
Resilient pipelines with retry, backoff, idempotency, and per-channel fault isolation
Near real-time synchronization at high transaction volume across all channels
.NET 8Azure FunctionsService BusAPI ManagementAzure SQLApp InsightsAWS LambdaSQSS3
● trace_id: pay-oauth-c31d · token: refreshed via key vault · partners: 5/5 healthy

Payment & Loyalty Integration Layer

Gateway PatternMiddleware IntegrationOAuth2 Token ManagementUnified API Contract

The Problem

Each payment and loyalty partner required a separate integration with different authentication flows, token lifecycles, and API contracts. With BNPL providers and regulated banking partners in scope, each integration carried distinct compliance requirements and transaction reliability expectations that made ad-hoc, per-partner approaches unsustainable as the partner count grew.

Architecture diagram
View architecture decisions

Key Design Decisions

  • APIM as the single contract surface — internal systems call one consistent endpoint regardless of partner. New integrations, version changes, and partner-side API updates don't require changes to the calling system.
  • Per-partner Azure Function isolates each partner's auth flow, token lifecycle, and request/response transformation. A failure or breaking change in one partner's integration is fully contained.
  • All OAuth2 tokens and API keys managed in Key Vault with rotation support — required for compliance with regulated banking partners and ensures no credentials exist in code or environment config.

How It Works

Internal systems send requests through APIM as a unified gateway. APIM routes to the appropriate per-partner Azure Function, which handles OAuth2 authentication, token refresh, and request/response transformation before calling the external partner API. Responses are normalized and returned end-to-end. Partners integrated: STC Qitaf, Al Rajhi Bank (Mokafaa), Tamara, Tabby, and Comarch CLM.

Impact

Partner onboarding time reduced by 60%
5 partners unified under one gateway contract
No changes to calling systems required for new partner additions
Full credential isolation and rotation via Key Vault
Azure FunctionsAPI ManagementOAuth2Key VaultApp Insights.NET 8REST APIs
● trace_id: otel-e2e-98b0 · spans: 15+ services · anomalies: 0 · alert: none

Observability & Reliability Architecture

Distributed TracingStructured LoggingShared Resilience PlatformOpenTelemetry

The Problem

As the integration surface grew to 15+ distributed Azure Functions and Service Bus pipelines, failures became increasingly difficult to trace. A failed transaction could span multiple hops — APIM, Functions, Service Bus, SQL, external partner — with no correlation between logs across services. Resilience behavior was also inconsistent: each service implemented retries and error handling independently, making the platform harder to reason about and extend reliably.

Architecture diagram
View architecture decisions

Key Design Decisions

  • OpenTelemetry over the Application Insights SDK directly — vendor-neutral instrumentation means the observability backend can change without re-instrumenting 15+ services.
  • Polly shipped as a shared platform package, not per-service configuration — new services inherit retry, circuit breaker, and idempotency behavior by default, making resilience the path of least resistance.
  • Correlation IDs propagated across every hop — one trace ID surfaces the full request chain from APIM through Functions, Service Bus, SQL, and external partner calls, without reconstructing timelines manually.

How It Works

All Azure Functions and Service Bus workflows emit structured logs and traces via OpenTelemetry, funneled into Application Insights and Azure Monitor. The shared Polly package enforces consistent retry policies, circuit breakers, and failure isolation across all services. Azure Monitor alerts are configured on anomaly thresholds — not just hard errors — enabling proactive detection before downstream systems are affected.

Impact

Full end-to-end trace coverage across 15+ services
Incident detection time significantly reduced
Resilience patterns standardized across all integration pipelines
Single correlation ID traces the full request chain across all hops
OpenTelemetryApplication InsightsAzure MonitorPollyService BusServerless

Agentic AI

In production

The next layer: integration platforms that can reason.

The Marketplace Support Agent is a production AI system I designed and built end-to-end for the e-commerce team. It answers operational questions — order tracking, fulfillment issues, daily order counts, and revenue by partner — across Amazon, HungerStation, Jahez, Trendyol, Speedi, and Nana.

A custom MCP server on Azure Functions exposes typed tools backed by dedicated stored procedures; an Azure AI Foundry agent orchestrates tool selection and partner detection; and a bilingual Arabic/English interface renders live results as structured cards.

Operational cards are parsed from structured tool output rather than model prose, keeping displayed order data grounded in the actual response.

How it flows
MCP ServerAzure FunctionsAzure AI Foundry6 Marketplace PartnersBilingual UI (AR/EN)Structured Data Rendering

What I Work With

My engineering toolkit.

Cloud & Architecture

Azure-first design · Serverless platforms · Microservices · Scalable enterprise architecture

Integration

Marketplace integrations · FinTech and loyalty systems · REST APIs · Webhooks · Messaging patterns

Data

Azure SQL · SQL Server · Stored procedures · Schema design · High-volume data processing

Reliability & AI

Observability · Distributed tracing · Retry strategies · Idempotency · Agentic AI & tool orchestration

Credentials

Boomi Certified Integration Professional

Boomi (Dell Technologies) · 2024

Certified

Testimonials

LinkedIn recommendations from people I've worked with.

All Recommendations
MA

Mohammad Al Haj

Head of E-Commerce Partnerships, Abdullah Al-Othaim Markets

“I had the pleasure of working closely with Mubarak on several marketplace integration projects at Al Othaim, including Amazon, Noon, and Hungerstation. From the start, he brought a sharp technical mind, clear communication, and a deep understanding of API structures and backend workflows. What really stood out was his ability to troubleshoot complex issues under tight deadlines and collaborate effectively across business and tech teams. We successfully launched integrations that directly impacted our e-commerce performance and operational efficiency — Mubarak is a rare mix of technical excellence and team spirit.”

Worked on the same team · July 2025

LinkedIn Profile
AO

Ahmad Osta

Applications Manager, Abdullah Al-Othaim Markets

“I am delighted to recommend Mubarak for his exceptional skills and contributions. He is a valuable asset and added value to any development team. He is always willing to share his knowledge and support team members, fostering a positive and productive work environment.”

Managed Mubarak directly · April 2024

LinkedIn Profile
MD

Mohammed Daggas

AI Experience Manager, DEEP.SA

“Mubarak is one of the best Developers that I have worked with, he gives meaning to the sentence "just think it and I'll do it". Extremely knowledgeable in what he does and always looking to improve, anyone would be lucky to have him in his team.”

Managed Mubarak directly · October 2023

LinkedIn Profile

Writing

I share what I learn.

Technical posts on integration architecture, resilience, observability, and AI systems — topics I work with in production.

All Posts
LLMs Don't Remember You
May 2026عربي

LLMs Don't Remember You

All LLMs — including Claude and ChatGPT — are stateless by design. The 'memory' you experience lives in the application layer, which stores conversations externally and re-sends them with every request. So where does the real intelligence lie? In context management.

AI FundamentalsLLMsContext Engineering
Read on LinkedIn
Embedding: How Machines Understand Meaning
May 2026عربي

Embedding: How Machines Understand Meaning

Computers don't understand text — only numbers. So how do we turn meaning into math? A breakdown of embeddings: vectors in a mathematical space where distance equals semantic similarity — the foundation behind modern LLMs, semantic search, and RAG systems.

AI FundamentalsEmbeddingsVector Databases
Read on LinkedIn
Circuit Breaker Pattern
Feb 2026عربي

Circuit Breaker Pattern

When an external API goes down, how do you protect the rest of your system? A walkthrough of the Circuit Breaker pattern using Polly — with real integration failure scenarios and how to isolate faults before they cascade.

ArchitectureResiliencePolly
Read on LinkedIn

Community

Before building systems, I built communities.

Early in my career I ran workshops and training programs in Sudan. That experience shaped how I communicate technical ideas, share knowledge, and support engineering culture.

The Programming Path — Photo 1The Programming Path — Photo 2The Programming Path — Photo 3
1 / 3
Graduates & Aspiring Developers2019

The Programming Path

A workshop covering learning paths, in-demand career tracks, frameworks & technologies, and how to get the most out of training courses.

👥 50+ graduates and aspiring developers attended

National Software Center — Entrepreneurship for Programmers Program
Telecom Tower, Khartoum, Sudan
Web Development Training — Photo 1Web Development Training — Photo 2Web Development Training — Photo 3
1 / 3
Government IT Engineers2018

Web Development Training

A specialized training course designed to build web development capacity for technical staff working in government institutions across Sudan.

👥 30+ government IT engineers attended

National Information Center — National Software Team
Khartoum, Sudan

Principles

The principles I design by.

The engineering beliefs I apply when building integration systems that must remain reliable under real production pressure.

01

Resilience by Design

I build for failure. Retries, circuit breakers, idempotency, and failure isolation are not afterthoughts — they're the foundation. When one partner API goes down, everything else keeps running.

02

Observability First

I don't ship anything I can't debug at 2 AM. Distributed tracing, structured logging, and correlation IDs across every service — because 'it works on my machine' doesn't count in production.

03

Data Integrity Always

I've learned that most integration failures are data problems in disguise. Strong schemas, idempotent writes, and consistent processing flows are what keep millions of transactions reliable.

04

Business Impact Drives Decisions

I measure my work in outcomes, not features. 40% less manual work. Sync delays from hours to minutes. Partner onboarding from weeks to days. That's what matters.

About

Building reliable systems in the space between platforms.

My career started in software development and grew across government, banking, energy, retail, and fintech. Across each industry, the same lesson kept returning: the hardest problems often live between systems, where contracts, data, reliability, and business processes meet.

Today I work as a Senior Integration Engineer in Riyadh, designing Azure-native, event-driven platforms and owning their architecture, implementation, delivery, data, observability, and production reliability end to end.

My direction is toward Integration and Solutions Architecture, while extending enterprise platforms with Agentic AI that remains grounded, observable, and safe to operate on live business data.

Get in Touch

Let's talk architecture.

Whether it is a technical conversation, consulting engagement, or a difficult integration problem, I am always open to connecting with people who care about building reliable systems.

Email LinkedInRiyadh, Saudi Arabia