AK

Ammar Kamil — Backend Engineer · Baghdad, Iraq

Systems where wrong is expensive.

Seven years in C# and ASP.NET Core on the parts of a product that have to reconcile: refunds that must balance, contracts that must hold up, records a citizen will rely on years later. I care about four things before a feature ships — how fast it is, how it behaves under load, what it exposes, and whether the next engineer can follow it.

  • 0 years in production
  • 0 sectors shipped into
  • 0 systems built on
«abstract» EngineeringConcern
  • # decidedBefore: ShipDate
  • + verify(): Evidence

Performance

Make the database do the work

  • Server-side projections and pagination instead of pulling collections into memory
  • Hunting N+1 access patterns out of EF query paths that cost response time under load
  • Stored procedures and ADO.NET where the query shape matters more than the abstraction
  • Caching the read paths that do not change per request, and measuring before and after

Scalability

Survive the second run

  • Hangfire jobs written for retries and duplicate execution, not just the happy path
  • Concurrency guards and idempotent bulk sends so a restart never double-charges or double-notifies
  • Batching and chunking so a long job does not grow unbounded in memory
  • Rate limits and third-party quotas treated as a design input — most outages start outside your code

Security

Assume the client is lying

  • JWT auth with role and policy-based authorization; OAuth and OTP flows
  • Every input validated server-side — frontend validation is a convenience, not a control
  • Guarding the quiet ones: privilege escalation, mass assignment, insecure direct object references
  • Biometric and personal data stored to the minimum verification needs, never to the maximum a schema allows

Patterns

Leave it readable

  • CQRS with MediatR — rules live in handlers, controllers stay thin
  • Repository pattern over EF Core, layered architecture, SOLID applied where it earns its keep
  • Database transactions wherever two pieces of state must never diverge
  • Tests as the contract: xUnit, Moq and FluentAssertions across unit and integration

The refund that didn’t balance

An order-level promotion discounts the whole basket, so no line item was ever paid at its list price. Refund a returned item at list price and you hand back money the customer never gave you. It is small on one order and systematic across all of them. Return part of this order and watch both the state machine and the two answers move.

Order lifecycle currentvisitednext
Order lifecycle state machine, highlighting the current state Placed Paid Delivered PartiallyReturned FullyReturned Refunded

Order #4471

Delivered

This demo needs JavaScript enabled.

Order-level promotion

What the customer paid
Subtotal
Promotion
Delivery
Charged

Refund

At list price

0

What the old path paid back.

At paid price

0

What the customer actually gave us.

Where the difference comes from
Returned List Promo share Refunded

How the split is decided

The promotion is allocated down to the individual unit, proportionally to what that unit contributes to the basket. A returned unit then refunds list price minus its own share, never the list price itself.

Proportional shares almost never land on whole dinars, and flooring every share leaves the allocated parts short of the promotion total — money that quietly disappears. The leftover is handed out by largest fractional remainder, so the parts always sum back to exactly the promotion that was granted.

Delivery is a service that was already performed. It comes back only when the whole order goes back — and when it does, the refund equals the amount charged, to the dinar. That equality is the property worth testing; everything else is arithmetic.

Refund path, after the fix
Sequence diagram of a partial return being priced and refunded Client API PricingEngine Ledger return 2 of 4 units allocate(promo, units) largestRemainder() refund(unit.pricePaid) 33,510 IQD

Money that has to reconcile

Orderii2024 — 2026

A high-volume e-commerce and logistics platform. I owned the pricing and financial layer across ordering, payment and delivery.

The problem
The pricing engine composed discounts, fees and payment rules across several order types, and the refund path treated a returned item as worth its list price. Once an order-level promotion existed, that was never true. Partial cancellations came back slightly wrong, in the customer’s favour, on every discounted order — a recurring source of incorrect charges nobody could pin down from a single invoice.
The decision
Push every order-level adjustment down to the unit at the moment the order is priced, and refund what was paid rather than what was listed. Assign rounding remainders by largest fractional share so allocated parts always sum back to the original total, and treat delivery as rendered unless the entire order returns.
The result
Partial refunds reconcile against what was captured, and a full return refunds the charged amount exactly. I also built OrderiiNow, a separate service for local orders, from data model and API surface through to production, and worked the slow EF query paths that were costing response time under load.
  • C#
  • ASP.NET Core
  • Entity Framework
  • SQL Server
  • Repository pattern

A fingerprint that has to hold up

Global Carrier2021 — 2024

E-contract and digital signing for the real estate sector. I built the server-side logic, the database schema and the APIs from scratch, including auth.

The problem
Replacing a handwritten signature with a fingerprint is not a capture feature. The signature has to stay verifiable long after signing, and the biometric data behind it is the one thing in the system a person can never rotate after a breach.
The decision
Capture, extract minutiae with Source AFIS, and match against a confidence threshold — storing what verification actually needs and no more, so the record stays provable without becoming the most valuable thing in the database. Contract documents and reports were laid out to exact positions with iTextSharp, with Excel exports through EPPlus.
The result
A manual paper signing process was replaced end to end, and the API surface was shaped alongside the frontend team to match the real signing flow rather than the database.
  • C#
  • ASP.NET
  • Web API
  • SQL Server
  • Source AFIS
  • iTextSharp
  • EPPlus

Records that outlive the system

Enjaz2018 — 2020

Software for Iraqi ministries and public-sector bodies: Justice, Health’s birth and death registration, the Pension system, the Portal, and the South Refineries support system.

The problem
Government output is printed onto pre-printed official forms, so a report is not done when the data is right — it is done when the ink lands inside the boxes. Meanwhile the numbers underneath belong to a citizen’s permanent record, and requirements changed between ministries mid-project.
The decision
A reusable document-generation layer over iTextSharp that renders data into fixed templates at exact positions, so a new form is a layout definition instead of new code. Reporting over large datasets went through stored procedures and ADO.NET where the query shape mattered more than the abstraction.
The result
Multiple public-sector systems stayed in production through continuous requirement changes. I wrote the unit tests around installment validation — missed payments and fines — in the Escan registration system, because that arithmetic decides what a citizen owes.
  • C#
  • ASP.NET MVC
  • ADO.NET
  • Stored procedures
  • SQL Server
  • iTextSharp
  • Anti-Money Laundering platform

    Compliance system for monitoring suspicious activity. Ingestion and validation of large flagged-individual datasets, name matching and verification against local and international watchlists, and secure APIs for external integration — built to the data-integrity and regulatory requirements set by compliance stakeholders.

  • OrderiiNow

    A separate service for local orders, taken from initial design and data model through to production.

  • Diet Zone

    Subscription meal planning. Recurring plan generation with per-user selections and nutritional calculation, modelled so pre-planned orders stay consistent while the user can still change them before fulfilment.

  • Baity

    Real estate and chalet reservation platform. Backend, 2026 to present.

«package» Toolkit
Languages
C#, SQL
Frameworks
ASP.NET Core, ASP.NET MVC, Web API
Data access
Entity Framework Core, LINQ, ADO.NET, stored procedures, EF migrations
Databases
PostgreSQL, SQL Server, MySQL
Architecture
RESTful API design, CQRS with MediatR, repository pattern, OOP, SOLID, layered architecture
Backend concerns
Background jobs and scheduling with Hangfire, JWT auth, role and policy-based authorization, OAuth and OTP flows, caching, rate limiting, pagination, query performance tuning, multi-language and multi-currency data
Testing
xUnit, Moq, FluentAssertions, unit and integration testing
Integrations
OneSignal, Twilio, Google and Apple Sign-In, payment and SMS gateways
Tools
AutoMapper, Hangfire, iTextSharp, EPPlus, Source AFIS, Swagger, Git
Spoken
Arabic (native), English (professional working proficiency)

Open to backend work on transactional systems — payments, billing, marketplaces, compliance. If your numbers have to agree with each other, that is the part I like.

end of flow