Engineering Leadership & Architecture

Hi, I'm Evan Delasota

Software Engineering Manager & Full-Stack Architect, Cloud Engineer, DevOps Engineer, Father, and Husband

Backend and full-stack engineer with 4+ years of experience architecting C#/.NET, Azure, and React systems at Temco Logistics, a nationwide white-glove final-mile delivery provider. Proven track record leading hands-on rebuilds of business-critical workforce and payroll platforms, multi-domain transactional migrations, and high-throughput ingestion pipelines handling millions of annual records.

Connect
Evan Delasota
4+
Years of Production Engineering
3.15M+
Annual Records & Files Ingested
37
Azure Enterprise Services Migrated

Architecture, Leadership & Production Ownership

Bridging complex business domains with resilient cloud architecture, strict transactional guarantees, and collaborative team leadership.

Domain Mastery

Enterprise Platform Architecture

Specialized in architecting, developing, and modernizing full-stack C#/.NET and React platforms. Extensive hands-on experience orchestrating complex 12-domain transactional migrations, HRMS and enterprise integrations, and mission-critical payroll calculation engines.

C#/.NET ASP.NET Core React MySQL Redis
Cloud Scale

Azure Cloud & Distributed Systems

Deep expertise provisioned across a 37-service Azure footprint. Designed and deployed event-driven architectures utilizing Azure Container Apps, Service Bus, Functions, Key Vault abstractions, managed identities, and secure hub-and-spoke VNet peering.

Azure Container Apps Service Bus Key Vault Databricks
People & Process

Engineering Leadership & Mentorship

Hands-on management integrating sprint planning, roadmap execution, and structured code reviews. Track record of mentoring junior and mid-level developers, establishing engineering standards, and fostering progressive ownership across cross-functional teams.

Technical Leadership System Design Agile/Scrum Mentorship
Production Grade

Security, Observability & Reliability

Committed to hardened systems with Entra ID (Azure AD), role-based access control (RBAC), token validation, structured logging with Application Insights, and automated test suites spanning xUnit and Playwright regression testing.

Entra ID xUnit Playwright App Insights

Professional Experience

4+ years of continuous advancement at Temco Logistics, a nationwide white-glove final-mile delivery provider, from full-stack engineer to lead developer to software engineering manager.

Software Engineering Manager

Temco Logistics — Pomona, CA
Feb 2025 – Present Full-Time
Hands-on application development, system design, and technical leadership alongside people management.
Workforce & Transactional Payroll Platform: Led the architecture and hands-on rebuild of an internally owned C#/.NET and React workforce and payroll platform, migrating 12 interdependent business domains and integrating a third-party HRMS, Databricks, MySQL, Blob Storage, Redis, Azure Communication Services, and Entra ID.
Unified Payroll & Revenue Logic: Unified critical revenue and payroll logic across operational views, employee and contractor payroll, time adjustments, and Excel/PDF outputs, encoding three-tier rates, guarantees, scheduled compensation changes, assignment rules, audit history, and transactional data-integrity controls.
HRMS Workforce Synchronization: Architected and implemented a database-first synchronization flow against a third-party HRMS using APIs, webhooks, transactional MySQL persistence, Azure Service Bus, and queued processors, moving employee changes from scheduled workforce exports to near-real-time event processing.
Multi-Schema Operational Event Ingestion: Led architecture and delivery of an Azure Container Apps event-ingestion platform handling three complex XML schemas across field-service events, order lifecycle events, and warehouse operations events.
37-Service Azure Cloud Migration: Owned hands-on migration of infrastructure within a 37-service Azure program: provisioned compute, storage, Key Vault, and managed-identity dependencies; moved existing workloads across subscriptions; and integrated services with hub-and-spoke VNets without significant program-level downtime.
High-Reliability Route & Stop Ingestion: Owned a retail-partner route integration that processes approximately 3.15 million JSON files and 7.35 million messaging responses a year at 99.997% ingestion success, a measured run rate sustained into 2026.
Secure Partner Document Exchange: Built secure external document-exchange workflows with token validation, rate limiting, audit logging, recoverable downloads, and durable acknowledgment retries.
Delivery Order Ingestion & Analytics Pipeline: Built edge-to-cloud middleware between a national retail partner and an internal warehouse management system on Cloudflare Workers and Azure, with dual-path delivery, a distributed circuit breaker, and raw-payload archival — 99.99% availability and zero observed message loss at roughly 7.8 million requests a month for about $21.40.

Lead Software Engineer

Temco Logistics — Pomona, CA
Apr 2024 – Feb 2025 Full-Time
Technical ownership of parts-management platform, secrets architecture, and developer mentorship.
Parts & Inventory Application: Delivered inventory and order-tracking enhancements for a parts-management web application, consolidating workflows into its version 2.0 release.
Key Vault & Deployments: Integrated Azure Key Vault through a dedicated service abstraction to centralize application secrets; introduced blue-green deployments for Azure web applications and APIs.
Encrypted Vendor Transfers: Built automated HR file-processing workflows for encrypted vendor transfers, replacing manual record handling.
Mentorship: Mentored junior developers through code reviews, implementation guidance, and progressively broader task ownership.

Full-Stack Developer

Temco Logistics — Pomona, CA
Mar 2022 – Apr 2024 Full-Time
Modernizing core enterprise logistics operations into scalable web services.
Desktop Modernization: Modernized legacy desktop functionality into a responsive web application, enabling device-independent access to operational workflows.
Cloud APIs & SQL Optimization: Built an Azure Functions web API and optimized SQL queries, views, stored procedures, and table partitioning for high-volume business-transaction processing.

Software Engineer Intern

HCL Technologies — Remote
Sep 2021 – Dec 2021 Internship
Cloud-native microservices development in a collaborative agile environment.
Developed a microservices project using Java/Spring, Docker, Kubernetes, and AWS in a collaborative development environment.

Key Systems & Case Studies

Representative enterprise architectures engineered to solve mission-critical operational challenges.

Featured case study 99.997% Success

High-Reliability Route & Stop Ingestion

Schema-validated, event-driven ingestion processing millions of partner files.

A national retail partner publishes route and stop data as a continuous stream of JSON files. I owned the integration that consumes it: a schema-validated, event-driven pipeline that turns each file into transactional route records and acknowledges it back to the partner, without a nightly batch window and without a queue that a single malformed file can stall.

3.15M
JSON files ingested per year at the measured run rate
99.997%
Ingestion success across the measured window
7.35M
Messaging responses per year at the same run rate
  • Validation at the edge. Files are checked against their schema before anything downstream sees them, so a bad payload is rejected at one known place rather than surfacing as a partial write three services later.
  • Failure is a path, not a halt. Rejects divert to a dead-letter lane with replay, which is what holds the success rate: the pipeline keeps draining while a handful of files wait for a human.
  • Throughput follows depth, not a clock. Queued processors scale on backlog instead of a schedule, so a partner-side burst costs latency rather than dropped files.
JSON Schemas Azure Service Bus Queued Processors MySQL Durable Retries Dead-Letter Replay
Route ingestion pipeline A retail partner feed arrives at an ingestion endpoint, passes schema validation, and is published to a Service Bus topic. Queued processors write to a transactional store and an object archive. Files that fail validation divert to a dead-letter lane and are replayed back onto the topic once corrected. Retail partner feed JSON route + stop files Ingestion endpoint Auth, rate limiting, receipt Schema validation Shape, required fields, dedupe Service Bus topic Durable, ordered per route Queued processors Scale on backlog depth MySQL Transactional Object store Raw archive Dead-letter Quarantine + alert Replay Corrected, re-queued reject retry Acknowledgment returns to the partner once the write commits
Sanitized architecture view. Partner identity, endpoints and internal topology are omitted; the shape of the pipeline and its failure path are what matter here.
Dual-Path Delivery

Delivery Order Ingestion & Analytics Pipeline

Built edge-to-cloud middleware between a national retail partner and an internal warehouse management system, decoupling the partner from downstream availability while preserving every raw payload for analytics.

Cloudflare Workers Cloudflare Queues Circuit Breaker Azure Service Bus Azure Functions
12 Domains Migrated

Workforce & Transactional Payroll Platform

Led the in-house rebuild of a vendor-managed platform spanning employee assignments, rate management, revenue reconciliation, time adjustments, contractor payroll, and audit history.

C#/.NET React MySQL Redis Blob Storage Entra ID
Batch → Event-Driven

HRMS Workforce Synchronization

Replaced scheduled workforce exports with a database-first event workflow built on third-party HRMS APIs and webhooks, transactional persistence, queues, and independent downstream processors.

HRMS API Azure Service Bus Webhooks Queued Processors MySQL
3 XML Schemas

Multi-Schema Operational Event Ingestion

Built a cloud-native ingestion platform that validates, routes, and normalizes three deeply nested XML schemas, correlating them into a single operational order-tracking view.

Azure Container Apps XML Schemas Event-Driven Containerized
37 Services Migrated

37-Service Azure Infrastructure Migration

Provisioned and orchestrated the hands-on workload migration within a 37-service Azure program: compute, storage, Key Vault, and managed-identity dependencies, moved across subscriptions and integrated over secure hub-and-spoke VNets without significant program-level downtime.

Hub-and-Spoke VNets Azure Key Vault Managed Identity Blue-Green CI/CD
Hardened Workflows

Secure Partner Document Exchange

Built secure document-exchange workflows between internal teams and external partners: temporary links, deterministic PDF packaging, atomic download controls, audit history, and recoverable acknowledgments.

Token Validation Rate Limiting Audit History Durable Retries

Technical Stack

The languages, services and patterns I work in day to day, not an exhaustive list of everything I have touched.

Languages & Frameworks

C# .NET / ASP.NET Core Entity Framework Core TypeScript React

Cloud, Compute & Data

Microsoft Azure Azure Container Apps Azure Service Bus Azure Functions MySQL Redis Databricks

Architecture & Delivery

Event-Driven Architecture Transactional Workflows RESTful APIs & Webhooks Message Queues & Processors Hub-and-Spoke VNets Blue-Green Deployments

Quality, Security & Observability

Entra ID (Azure AD) Role-Based Access Control (RBAC) Application Insights xUnit Playwright

Education & Certifications

Formal academic foundation in computer science supplemented with verified cloud certifications.

B.S. in Computer Science

California State University, Fullerton

Comprehensive studies in data structures, algorithms, operating systems, software engineering methodologies, and database systems.

Azure Fundamentals

Microsoft Certified

Demonstrated foundational knowledge of cloud concepts, Azure core services, security, privacy, compliance, and cloud pricing models.

AWS Certified Cloud Practitioner

Certified Cloud Practitioner

Amazon Web Services (AWS)

Validated overall understanding of the AWS Cloud platform, covering foundational cloud computing concepts, core services, and security.

Get in Touch

Open to senior, staff and principal individual-contributor roles in backend and distributed systems. Remote or hybrid, with a preference for Orange County or Los Angeles, though location is flexible for the right team.

Direct Channels

Feel free to reach out directly via email, connect on LinkedIn, or review my code on GitHub. I typically respond within 24 hours.

Email
evan.delasota@gmail.com
Location
Orange County, CA

Send a Message

Submissions are delivered by Formspree, which processes the name, email and message you enter in order to forward them to me. Nothing is stored on this site, and I do not use these details for anything but replying. If you would rather not use a third party, email me directly.

engineering-ops-console

Reliability, visualised

Every dot below is one ingested event. This is 100,000 of them — about eleven days at the measured run rate. Three of them failed.

99,997 succeeded 3 failed

The three failures were detected, isolated and replayed from the dead-letter queue. None of them required a partner to tell us first.

Reliability isn’t the absence of failure. It’s the ability to detect, isolate, recover, and learn.

Workforce & Payroll Operations Platform

Sanitised component view. Select a component to see why it was chosen, the failure it addresses, what it costs to run, and how it is watched.

Request path

Cross-cutting

Azure Key Vault

Secret ProductionConnectionString
Value ********************************

Nice try.

Secrets belong in Key Vault — not source control.

Delivery Order Ingestion & Analytics Pipeline

Cloudflare edge Resilient middleware

Resilient edge-to-cloud middleware connecting partner orders, warehouse operations, and analytics.

Route-summary reports carried stop-level information but never the line-item detail — SKU, service code, quantity — that deeper operational analysis needed. I built the core ingestion and resilience layers: standardized delivery-order XML from a national retail partner is accepted at the Cloudflare edge, validated and checksummed, and delivered into Azure without making the sender depend on downstream availability. When Azure is unreachable the same message lands on a durable edge queue and the sender still receives an accepted response. Azure Functions then archive the original payload and independently forward it to the warehouse management system, leaving a replayable source behind.

99.99%
Measured availability across the ingestion path
~7.8M
Requests a month, at about three per second sustained
$21.40/mo
Operating cost at that volume, across both clouds

The challenge

Daily route reports summarised operations but never carried the full delivery payload, which capped what the business could forecast about revenue, parts and route preparation. Wiring the partner straight into the warehouse management system would have solved the detail problem and created a worse one: an external sender coupled to internal availability.

  • Payloads arrive as external XML on a public endpoint, so invalid, oversized or corrupted content has to fail before it reaches anything internal.
  • An Azure Service Bus outage could not be allowed to become a lost source message.
  • Extended downstream downtime could not turn into a retry storm against a dependency already known to be unhealthy.
  • Warehouse delivery and analytical archival needed to succeed and fail independently of one another.
  • Raw payloads had to survive for replay and audit — including for analytical models that did not exist yet.
  • Cloudflare Workers could not take a dependency on the unsupported Node.js Azure SDK.
  • The operational picture had to hold together across two cloud platforms, not one.
Architecture and design
  1. Edge ingestion as the boundary. The Worker validates method, content type, payload size and XML structure, then builds a tracked message carrying its own identifiers, a SHA-256 checksum and routing metadata — without altering a byte of the original payload.
  2. Two delivery paths, one contract. Normally the message goes straight to Azure Service Bus. If Azure is unreachable or the circuit is open, the same message lands on a Cloudflare Queue and the sender still receives an accepted response. A separate consumer drains that queue in batches, retries transient failures, and moves exhausted or permanently invalid work to a dead-letter path.
  3. A circuit breaker that is shared, not local. Breaker state lives in Cloudflare KV rather than inside one Worker instance, so edge executions and queue consumers hold the same view of downstream health. Closed attempts direct delivery, open diverts straight to the queue, half-open probes for recovery; a successful probe closes it, another failure reopens it.
  4. A transport that belongs in the runtime. The unsupported Node.js Service Bus SDK was replaced with a REST client that runs natively inside Workers, removing a runtime-compatibility risk while keeping both the direct path and the fallback intact.
  5. Fan-out on the Azure side. Service Bus decouples ingestion from two independent Function workflows. One revalidates the payload, recomputes the checksum, dead-letters empty or corrupted content, and stores the raw XML in Blob Storage with its operational metadata. The other independently checks integrity and forwards to the warehouse management system under retry, timeout and circuit-breaker policies. Neither completes its message until its own work has actually succeeded.
  6. An archive, not an extract. The archival path keeps the complete source payload rather than the subset the warehouse management system happens to need today, so a later analytical model can be run against the original event instead of asking the partner for it again.
  7. Security and operational signal. Structure and checksum validation, TLS in transit, an API key at the edge boundary, Key Vault for downstream secrets, managed identity on Azure resources, environment-specific configuration, and structured logging of message, path, latency, retry count and circuit state — with queue depth, success rate, circuit state and latency as the things actually watched.

Measured outcomes

  • 99.99%Availability across the ingestion path
  • ZeroObserved message loss
  • ~50 msDirect-path latency from the edge into Azure
  • 3 / secSustained request rate, about 7.8 million a month
  • ~$21.40Monthly operating cost at that volume

Outcome

The result is a resilient middleware boundary between the retail partner and the internal warehouse management system. External delivery no longer depends directly on warehouse or Azure availability; the edge provides fast global ingress and persistent buffering while the circuit is open; and Service Bus keeps storage and forwarding from being able to break one another. End-to-end checksums protect integrity across both clouds, failures became observable and recoverable rather than silent or sender-facing, and a new consumer can be added without touching the external contract. Raw payloads land in an analytics-ready Azure landing zone, with relational Databricks transformation as the planned downstream layer.

My role

I built the core technical implementation: the edge request handler, XML validation and message construction, routing, the KV-backed circuit breaker, the Service Bus integration, the queue fallback and its consumer, retry and dead-letter behaviour, Worker testing and deployment, and the Azure-side Service Bus handlers.

Where this stops. The ingestion, resilience, archival and forwarding layers are built and deployed. The relational Databricks schema and the analytical publication layer were paused alongside the wider program and remain planned work, not shipped work.

Edge-to-Azure ingestion pipeline Delivery-order XML from a retail partner reaches a Cloudflare Worker, which validates it and computes a checksum. A circuit breaker held in Cloudflare KV decides between direct delivery to Azure Service Bus and a durable Cloudflare Queue drained by a batch consumer. On the Azure side, Service Bus fans out to two independent functions: one archives the raw payload to Blob Storage, the other forwards it to the warehouse management system. A planned Databricks layer sits below the archive. Retail partner feed Delivery order XML Request handler Method, type, size, XML Validate + checksum SHA-256, message identity KV circuit breaker Closed / open / half-open Azure Service Bus REST client from the edge Cloudflare Queue Degraded-mode buffer Batch consumer Retry + dead-letter Archive Checksum, store Forward Retry + breaker Blob storage Raw XML archive Warehouse Mgmt system Databricks → SQL Planned analytics layer open drain
Sanitised architecture view. The edge path runs down to Service Bus; Azure fans out below it. The dashed node at the foot is planned analytical work, not deployed work.
Technology
Cloudflare Workers TypeScript Cloudflare KV Cloudflare Queues Azure Service Bus .NET 9 Azure Functions Azure Blob Storage Databricks XML SHA-256 Azure Key Vault Managed Identity Application Insights Vitest

Workforce & Transactional Payroll Platform

Platform rebuild Payroll safety

Modernizing a 12-domain platform responsible for workforce operations and revenue-critical payroll.

A vendor-managed workforce system was replaced with an internally owned C#/.NET and React platform spanning employee assignments, time adjustments, contractor payroll, tiered rates, guarantees, scheduled compensation changes and audit history. The rebuild integrated a third-party HRMS, Databricks, MySQL, Redis, Blob Storage, Azure Communication Services and Entra ID, and moved twelve interdependent business domains in dependency order without breaking the references between them. The platform had to calculate payroll consistently across operational screens, administrative workflows, exports and downstream integrations while preserving transactional integrity.

12 domains
Interdependent business domains, migrated in dependency order
3 rate tiers
Location, company and individual rates, with guarantees and scheduled increases
2 periods
Payroll periods cleared in pre-launch validation, not post-launch acceptance

The challenge

  • Employee assignments, activity data, rates, guarantees, payroll calculations and reports all depended on one another, so nothing could be rebuilt in isolation.
  • Legacy data was denormalised: a single schedule row could stand for several employee assignments.
  • Original identifiers had to be preserved where required, or referential continuity would break at the seams.
  • Operational revenue and payroll reports could not be allowed to drift into separate, contradictory rule sets.
  • Cutover needed genuine confidence from HR, payroll administrators and operations — without overstating pre-launch validation as production acceptance.
Architecture and design
  1. Clean, domain-oriented architecture. React and TypeScript carry the operational interface; ASP.NET Core services isolate scheduling, rates, revenue, payroll, reporting, migration and external integrations behind their own boundaries.
  2. Dependency-aware migration. Twelve domains moved in a controlled sequence with dry-run validation, duplicate detection, foreign-key checks, transformation rules and reconciliation reporting. Denormalised schedule rows were expanded into normalised employee assignments while preserving the identifiers other records still pointed at.
  3. One calculation pipeline, two audiences. Operational revenue and payroll reports share the same activity-resolution and calculation logic, so a report-specific implementation cannot quietly drift away from the operational source it is meant to describe.
  4. Business-rule depth as a first-class requirement. Three-tier rates, guarantees, scheduled compensation changes, manual assignments, scheduled services, activity overrides, time-punch validation and Excel/PDF outputs are platform behaviour rather than spreadsheets living beside the platform.
  5. Built to be owned, not just launched. Entra ID authentication, location-scoped authorisation, managed identities, hybrid Redis and in-memory caching, audit logging, correlation IDs, health checks and standardised Problem Details responses are what make production ownership possible after the rebuild team moves on.

Outcome

The company gained an internally controlled, auditable workforce platform instead of remaining dependent on a vendor-managed implementation. Parallel reconciliation reduced cutover risk, and two payroll periods cleared validation ahead of the planned production launch. The calculations, reports and supporting data now live inside one governed platform that the team can change, explain and audit.

My role

I led the architecture, the hands-on implementation, the migration strategy, stakeholder testing and the production-readiness work across every domain listed above.

Where this stops. “Transactional” here means transactional integrity: the platform prepares, calculates, reconciles and reports payroll. It is not a payroll-disbursement system. The two cleared periods were pre-launch validation, not a claim about universal production payroll accuracy.

Workforce platform architecture A React single-page application authenticated with Entra ID calls an ASP.NET Core API, which routes to domain services for employee assignments, rates and revenue. Those services use a shared calculation engine that writes to MySQL with audit history, and produce revenue and payroll reports. External sources — a third-party HRMS and Databricks — reach the domain services through a sync and ingestion layer. A Redis cache serves the calculation engine, and Blob Storage with Azure Communication Services support report delivery. React 19 SPA Entra ID sign-in ASP.NET Core API Location-scoped authz Domain services Assign, rates, revenue Shared calc engine One activity + pay path MySQL + audit Transactional, EF Core Reports + exports Revenue, payroll, Excel External sources HRMS, Databricks Sync + ingest Normalise, reconcile Redis cache Rates + lookups Blob + ACS Files, notifications
Sanitised architecture view. The user path runs down the left column; external sources and supporting services join it from the right where they are actually used.
Technology
.NET 10 ASP.NET Core React 19 TypeScript EF Core MySQL HRMS Integration Databricks Redis Azure Blob Storage Azure Communication Services Entra ID Application Insights

HRMS Workforce Synchronization

Event-driven integration Batch → near real time

Transforming scheduled HRMS exports into reliable, traceable workforce updates.

A third-party HRMS supplied workforce changes through scheduled exports rather than a dependable event stream, which delayed downstream account and application updates and tied several internal systems to one schedule. I redesigned the integration around the provider's APIs and webhooks, a transactional MySQL source of truth, and asynchronous Azure messaging. A lightweight ingress path validates and queues each event; an orchestrator resolves the authoritative employee record and persists it once; independent consumers then synchronise downstream platforms without holding the original request open while they work.

2-phase
Synchronous ingestion, then asynchronous processing — the sender waits for neither
50–100 ms
Documented validation-and-queueing time for the ingress path — a design measurement, not a verified production SLI
3 events
Employee creation, update and termination, each handled on the same path

The challenge

  • Employee changes needed to reach identity, analytics and operational systems faster than a scheduled export allows.
  • The provider could not be made to wait while every downstream dependency finished its own work.
  • A failure in one consumer could not be allowed to stop the other systems from receiving the same change.
  • Duplicate, replayed and partially processed events all needed safe handling rather than best-effort handling.
  • The rollout needed feature flags and fallback paths, not a single high-risk cutover.
Architecture and design
  1. Fast, authenticated ingress. The webhook endpoint validates credentials and payload structure, places accepted work on a queue, and acknowledges immediately — so the caller's retry logic stays quiet whatever happens downstream.
  2. Database-first orchestration. The processor retrieves the complete employee record, updates the transactional database, and tracks event processing so a replayed event is recognised rather than reapplied.
  3. Decoupled distribution. A normalised employee-change event is published to Azure Service Bus. Dedicated processors update identity, analytics and operational platforms independently of one another.
  4. Failure isolation and recovery. Retryable failures back off exponentially. Invalid or exhausted messages are isolated for investigation and replay instead of blocking unrelated employee changes behind them.
  5. Operational visibility. Event IDs, queue depth, execution time, retry count and per-consumer outcomes give support an end-to-end trail, which is what makes "did this person's change land?" an answerable question.

Outcome

The event-driven path became the primary mechanism for employee changes while controlled fallback options remained available. Downstream failures became isolated and recoverable rather than schedule-wide, new consumers can subscribe without anyone touching the ingestion endpoint, and employee changes move toward near-real-time processing instead of waiting for the next report batch.

My role

I designed and built the synchronisation service end to end: the webhook ingress and its validation, the orchestrator and its idempotency tracking, the transactional persistence layer, the normalised event contract published to the bus, the downstream consumers, and the feature-flagged rollout with its fallback paths.

Where this stops. The 50–100 ms figure is the documented ingestion measurement for the validate-and-queue step. It is not a production service-level indicator, and it does not describe end-to-end propagation to every downstream consumer.

Event-driven workforce synchronisation Employee lifecycle events arrive from a third-party HRMS through APIs and webhooks. A validate-and-queue step authenticates and acknowledges quickly. A sync orchestrator resolves the full employee record and persists it once to transactional MySQL, then publishes a normalised change event to Azure Service Bus, where independent consumers update identity, analytics and operational systems. Consumer failures retry with exponential backoff, and exhausted work is isolated in a dead-letter path for replay. HRMS API + webhook Employee lifecycle events Validate + queue Auth, shape, fast ack Sync orchestrator Resolves the full record Transactional MySQL Persisted once, idempotent Azure Service Bus Normalised change event Independent consumers Identity, analytics, ops Retry Exponential backoff Dead-letter Isolated for replay fail
Sanitised architecture view. The synchronous half ends at the queue; everything below it runs on its own clock, and a consumer that fails takes only itself out.
Technology
.NET 9 Azure Functions HRMS API Webhooks EF Core MySQL Azure Storage Queue Azure Service Bus Microsoft Graph Azure Key Vault Application Insights

Multi-Schema Operational Event Ingestion

Multi-schema ingestion Production deployed

One event-driven platform for three independently evolving XML schemas.

A shared ingestion service had to process three structurally different event families — order lifecycle events, field-service events and warehouse operations events — each with a deeply nested XML schema, each arriving on its own schedule, without letting schema-specific logic create tightly coupled or fragile workflows. I led the platform architecture and the core API and container delivery that turned those payloads into a queryable tracking model. The team then extended the correlation layer so all three families link by a shared order identifier, with dispatch-reference handling for the events that redelivery can duplicate.

~12,000
Field-service events processed at the documented measurement point
~1,300
Order lifecycle events across the same window
~4,400
Warehouse operations events — about 17,700 combined, measured then, not a lifetime total

The challenge

  • The XML contracts ran four to five levels deep across roughly 150 defined elements.
  • Schemas carried optional fields, unbounded collections, mixed occurrence rules and several data types — the combinations, not the depth, are what break a parser.
  • Events belonging to one delivery could arrive at different times and through different paths.
  • Production schemas introduced nullability differences that had to be absorbed without losing the event.
  • A redelivery could create a new dispatch reference while still belonging to the same customer journey.
  • The system needed both live API processing and a path for staged event files.
Architecture and design
  1. Schema-specific transcription. Each event family has its own models and mapping logic, so schema differences stay explicit and reviewable instead of disappearing inside one generic parser that nobody can reason about.
  2. Two ways in. The service accepts HTTP event ingestion and also retrieves staged event data from Azure storage, so a backfill or a replay does not need a different system.
  3. A normalised tracking model. Controllers, services and repositories translate source payloads into a consistent tracking database, rather than leaking raw partner contracts through to the portal.
  4. Cross-event correlation. A shared order identifier links order, field-service and warehouse activity into one response for the front end, while dispatch references still support event-level lookup and redelivery cases.
  5. Production hardening. Logging spans the API, service, repository and portal layers. Generated test files, schema-specific tests, unit tests and end-to-end validation cover both normal and nullable payload variants.
  6. Repeatable delivery. The API is containerised, published to a registry, deployed to Azure Container Apps and wired to GitHub Actions, so a schema fix ships the same way every time.

Outcome

The project delivered a production order-tracking system with both front-end and back-end components. Rather than asking anyone to understand three separate event feeds, the portal assembles one coherent order history from order, field-service and warehouse activity — which is the difference between having the data and being able to answer "where is my delivery?".

My role

I led the platform architecture and delivered the core API and container work: the schema-specific models and mapping, both ingestion paths, the normalised tracking model, containerisation, and the CI/CD pipeline. The team extended the correlation layer afterwards.

Where this stops. The event counts above are a historical measurement point, not current lifetime totals. This platform is the multi-schema normalisation and tracking story; the edge-ingestion and resilience work is a separate system with a separate architecture.

Multi-schema ingestion and order tracking Three XML event families — order lifecycle, field-service and warehouse operations events — converge on a schema router that selects per-family models. Typed deserialisation handles nullability variants, then a service and repository layer normalises each payload into a tracking database. A correlation step links all three families by a shared order identifier and feeds an operational tracking portal. Staged XML files from Azure storage join at the deserialisation step. Order lifecycle ~1,300 events Field service ~12,000 events Warehouse ops ~4,400 events Schema router One model per family Typed deserialise Nullability variants Staged XML Azure storage Service + repo Normalise to tracking Tracking database One order history Correlation Links all three families Tracking portal Unified order view
Sanitised architecture view. Three schemas stay separate exactly as long as they need to, and converge once there is a normalised model to converge into.
Technology
C#/.NET ASP.NET Core XML JSON REST APIs Azure Blob Storage Docker Azure Container Registry Azure Container Apps GitHub Actions JWT Authentication

Secure Partner Document Exchange

Secure delivery 101 tests at release

Auditable, failure-tolerant document workflows for external partners.

Sending sensitive business documents to an external partner used to mean manual downloads, packaging by hand, shared-drive coordination and email whitelisting — with little central evidence of who actually opened what. I built and hardened a portal that synchronises approved content from an upstream document system of record, creates temporary external links, validates every anonymous request, and delivers original files, merged PDFs or ZIP packages through a dedicated public experience. Successful downloads are recorded locally and create durable acknowledgment work without making the recipient wait on a remote system.

101 tests
Passing at release validation, covering the public flow end to end
Static SSR
The external recipient path renders separately from the internal application
Atomic reserve
Download limits reserved before packaging, so a failed build costs nobody an attempt

The challenge

  • External partners receiving a link are anonymous by design, while the content they receive is confidential.
  • Links must expire, support revocation, and hold their download limits under concurrent requests.
  • Upstream content can be missing, malformed, wrongly typed or replaced between the link being sent and the link being used.
  • Multi-document downloads must preserve the sender's chosen order without unbounded memory use.
  • A failed package build must not consume a successful download.
  • An acknowledgment failure on the remote system must not turn an otherwise successful delivery into an error for the recipient.
Architecture and design
  1. Scoped synchronisation. Only approved business matters and documents become eligible for sharing, and reconciliation runs only after a complete successful upstream read — so a partial outage upstream cannot deactivate valid content on this side.
  2. An isolated public experience. The external flow uses static server rendering and its own assets rather than exposing the internal application framework. Page, validation and download routes all answer to one centralised authorisation policy instead of three similar ones.
  3. Defensive document retrieval. Upstream responses are checked for the expected content type, non-empty content and a valid PDF signature. An invalid payload fails closed rather than becoming a corrupt file in a recipient's hands.
  4. Deterministic packaging. A single file streams straight through. Multiple PDFs merge in the sender's chosen order under bounded input, output, page and concurrency limits. Unsupported or mixed sets fall back to a controlled ZIP.
  5. Atomic download accounting. A reservation workflow validates the link and reserves the available download in one step; the attempt completes only once a package has actually been built, and failures release or fail the reservation rather than silently spending it.
  6. Audit now, acknowledge later. A successful delivery writes local audit history and persists retryable acknowledgment work for the upstream system. A remote outage delays the acknowledgment, never the recipient's file.

Outcome

The portal gives internal administrators a controlled, auditable alternative to distributing documents by hand. The public flow was validated with 101 passing tests and carries centralised token controls, rate limiting, anonymous request auditing, secure response headers, bounded packaging and recoverable remote acknowledgment — so "did they get it, and when?" has an answer that does not depend on anyone's memory.

My role

I built and hardened the portal: the scoped synchronisation, the isolated public experience and its centralised authorisation policy, defensive document retrieval, the packaging pipeline, atomic download accounting, and the audit-and-outbox path behind the acknowledgment.

What is deliberately not here. This description stays at the level of architecture and control. Token formats, header names, scoping identifiers, folder conventions, recipient rules, rate thresholds, locking strategy and endpoint routes are all omitted on purpose — a public case study about secure delivery should not be a map of it.

Secure partner document exchange An internal administrator selects a business matter and its documents. An upstream synchronisation step admits only approved content into a portal metadata store, from which a temporary, revocable share link is created. An external recipient opens a statically rendered page; a central authorisation step validates the link and atomically reserves a download, content checks run against the upstream files, a package is built as a single file, a merged PDF or a ZIP, and the download is delivered. Completed downloads write audit history and a retryable acknowledgment back to the upstream system. Internal admin Selects matter + files Upstream sync Approved scope only Portal metadata Links, state, audit Temporary link Expiring, revocable External recipient Anonymous, static SSR Central authorisation Validate + reserve Package builder File, merged PDF or ZIP Download Delivered to the recipient Content checks Type, size, signature Audit + outbox Retryable ack
Sanitised architecture view. Routes, token formats and scoping rules are omitted on purpose; what is shown is the order the checks happen in, which is the part that matters.
Technology
.NET 9 ASP.NET Core Razor / Static SSR EF Core MySQL PDFsharp Azure Communication Services Rate Limiting Background Workers Structured Audit Logging