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. I led the hands-on rebuild of a business-critical workforce and payroll platform, including its 12-domain migration, and own high-throughput ingestion pipelines that handle millions of records a year.

Download Resume Get in Touch
Connect
Evan Delasota
12
Business domains rebuilt in-house off a vendor platform
37
Azure components migrated in ~6 weeks, no significant downtime
~$21/mo
To run 7.8M partner requests a month at 99.99% availability
Selected Work

Case Studies

The systems behind the numbers above: the problem each one solved, the decisions that shaped it, and what changed as a result.

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 Service Components

Enterprise Azure Application Migration

Led the dependency-aware migration of an enterprise application portfolio across Azure subscriptions: application compute, storage, secrets, workflows, networking, identity, CI/CD, and external integrations.

App Service Azure Functions Azure Key Vault Hub-and-Spoke VNets 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
Career Trajectory

Professional Experience

4+ years at Temco Logistics, a nationwide white-glove final-mile delivery provider, progressing from Full-Stack Developer to Lead Software Engineer to Software Engineering Manager.

Temco Logistics

Pomona, CA · Mar 2022 – Present 2 promotions in 3 years

Software Engineering Manager

Feb 2025 – Present
Hands-on application development, system design, and technical leadership alongside people management.
Workforce & Payroll Platform: Led the architecture and hands-on rebuild of a vendor-managed workforce and payroll system as an internally owned C#/.NET and React platform: 12 interdependent business domains, one shared revenue and payroll calculation engine, and an HRMS synchronization that moved employee changes from scheduled exports to near-real-time events. Case studies
Partner Integrations: Owned the partner-facing data pipelines: route ingestion at 99.997% success on ~3.15 million files a year, a run rate measured over eight months and sustained since; an edge-to-Azure delivery-order pipeline at 99.99% availability for about $21.40 a month; a three-schema XML event-ingestion platform on Azure Container Apps; and secure partner document exchange. Case studies Route ingestion
Enterprise Azure Migration: Led the application-infrastructure workstream of a 37-component Azure migration, provisioning compute, storage, Key Vault, and managed identities, retargeting CI/CD, and cutting over 10 application workloads to hub-and-spoke networking in dependency-aware waves without significant program-level downtime. Case study
Engineering Leadership: Paired hands-on architecture and delivery with people management: sprint planning, roadmap execution, structured code reviews, and the engineering standards the team builds against.

Lead Software Engineer

Apr 2024 – Feb 2025
Technical ownership of a 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 a junior developer through code reviews, implementation guidance, and progressively broader task ownership.

Full-Stack Developer

Mar 2022 – Apr 2024
Moved core logistics workflows off legacy desktop software and onto the web and cloud APIs.
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.

HCL Technologies

Remote

Software Engineer Intern

Sep 2021 – Dec 2021
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.
Capabilities

Skills & Expertise

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

Languages & Frameworks

Builds full-stack C#/.NET and React platforms, from HRMS and enterprise integrations to the payroll calculation engine behind a 12-domain rebuild.

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

Cloud, Compute & Data

Provisioned and migrated a 37-component Azure footprint, and builds event-driven systems on Container Apps, Service Bus, and Functions with Key Vault, managed identities, and hub-and-spoke networking.

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

Architecture & Delivery

Designs event-driven, transactional workflows that fail safely: queued processors, dead-letter replay, circuit breakers, and blue-green deployments.

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

Quality, Security & Observability

Builds hardened systems with Entra ID, role-based access control, token validation, structured logging in Application Insights, and automated xUnit and Playwright regression suites.

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

Engineering Leadership

Pairs hands-on engineering with people management: sprint planning, roadmap execution, structured code reviews, engineering standards, and mentorship toward progressively broader ownership.

Technical Leadership System Design Code Review Agile/Scrum Mentorship
Background

Education & Certifications

B.S. in Computer Science

California State University, Fullerton
Graduated 2022 · Fullerton, CA

Azure Fundamentals

Microsoft Certified
Microsoft · Exam AZ-900
AWS Certified Cloud Practitioner

Certified Cloud Practitioner

Amazon Web Services (AWS)
View on Credly
Let's Connect

Get in Touch

Open to senior and staff 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 by email or connect on LinkedIn. I typically respond within 24 hours.

Email
evan.delasota@gmail.com
Location
Orange County, CA
LinkedIn
linkedin.com/in/evan-delasota

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, visualized

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

Failures like these are detected, isolated, and replayed from the dead-letter queue. None of them requires a partner to tell us first.

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

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 summarized 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 behavior, Worker testing and deployment, and the Azure-side Service Bus handlers.

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
Sanitized 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 denormalized: 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. Denormalized schedule rows were expanded into normalized 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 behavior rather than spreadsheets living beside the platform.
  5. Built to be owned, not just launched. Entra ID authentication, location-scoped authorization, managed identities, hybrid Redis and in-memory caching, audit logging, correlation IDs, health checks, and standardized 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 Normalize, reconcile Redis cache Rates + lookups Blob + ACS Files, notifications
Sanitized 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 synchronize 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 recognized rather than reapplied.
  3. Decoupled distribution. A normalized 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 synchronization service end to end: the webhook ingress and its validation, the orchestrator and its idempotency tracking, the transactional persistence layer, the normalized 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 synchronization 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 normalized 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 Normalized change event Independent consumers Identity, analytics, ops Retry Exponential backoff Dead-letter Isolated for replay fail
Sanitized 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 normalized 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 containerized, 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 normalized tracking model, containerization, 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 normalization 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 deserialization handles nullability variants, then a service and repository layer normalizes 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 deserialization step. Order lifecycle ~1,300 events Field service ~12,000 events Warehouse ops ~4,400 events Schema router One model per family Typed deserialize Nullability variants Staged XML Azure storage Service + repo Normalize to tracking Tracking database One order history Correlation Links all three families Tracking portal Unified order view
Sanitized architecture view. Three schemas stay separate exactly as long as they need to, and converge once there is a normalized 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 Full audit trail

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 synchronizes 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.

100% audited
Every anonymous request and successful download is recorded, so delivery is provable
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 synchronization. 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 centralized authorization 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 end to end before release and carries centralized 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 synchronization, the isolated public experience and its centralized authorization 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 synchronization 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 authorization 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 authorization Validate + reserve Package builder File, merged PDF or ZIP Download Delivered to the recipient Content checks Type, size, signature Audit + outbox Retryable ack
Sanitized 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

Enterprise Azure Application Migration

Portfolio migration 37 service components

Moving an interconnected application portfolio between Azure subscriptions without breaking what connected it.

An enterprise application portfolio had grown up inside a legacy Azure subscription: web and container apps, serverless functions, storage, secrets, messaging, workflow automation, observability, and external partner integrations, wired together through a dependency network nobody had written down in one place. I led the application-infrastructure workstream of a cross-subscription migration, moving the assigned workloads and everything they depended on into a new Azure environment while preserving the integrations already in flight. Thirty-seven service components across seven resource categories moved over roughly six weeks, with no significant program-level downtime reported.

37 components
Azure service components migrated, across seven resource categories
10 workloads
Application compute workloads: app, container, and function services
~6 weeks
Execution window, from first deployment to the migration milestone

The challenge

The risk was never recreating individual Azure resources. It was preserving the behavior of systems that only worked because of what they were connected to.

  • Every workload depended on a different combination of databases, storage containers, queues, secrets, messaging, workflow automation, monitoring, and external endpoints.
  • One synchronization workload alone needed a database, a Key Vault, a message bus, storage, telemetry, communication services, three Logic Apps, and an external file-transfer endpoint.
  • A missing network route, identity permission, secret, storage trigger, or partner connection leaves an application deployed but operationally incomplete — and it looks perfectly healthy from the portal.
  • Partner integrations had to keep working across the move. An external contract is not something to renegotiate on a migration schedule.
  • Several workloads leaned on the same shared services, so the order things moved in mattered more than how fast they moved.
Migration approach
  1. A dependency graph, not a resource list. Each workload was written down as its compute resource plus its runtime secrets, storage and queue dependencies, database connections, messaging infrastructure, monitoring, internal shared services, and external integrations. That is what stops an application being called migrated because its primary compute resource happens to be running. Observability counted as a dependency, not as follow-up work.
  2. Shared services first. Key Vaults, storage accounts, communication services, workflow services, database access, and the identities behind them moved before any application cutover, so deployments could target a working destination instead of leaning on temporary production workarounds.
  3. Networking and identity as part of the move. Workloads were attached to the hub-and-spoke network and given managed identities, Key Vault access, private service resolution, cross-subscription permissions, and least-privilege access. Deployment access and runtime identity stayed separate security boundaries rather than collapsing into one convenient credential.
  4. Deployment paths rebuilt, not deferred. Every major application carried explicit work for its development deployment, its production deployment, its CI/CD configuration, its networking, and its dependencies — and development was exercised in the destination before production followed. Repeatable deployment was part of the migration, not post-migration cleanup.
  5. The external contract stayed fixed. The migration changed where infrastructure sat without asking partners, file-transfer providers, or messaging endpoints to redesign anything to suit it.
  6. Cutover in dependency-aware waves. Shared infrastructure first, then the lower-risk workloads, then the systems with the largest integration surfaces. Each wave kept the blast radius small enough that a problem could be isolated before the next group moved.

Measured outcomes

  • 37Azure service components migrated
  • 10Application compute workloads
  • 7Resource categories
  • ~6 weeksExecution window
  • NoneSignificant program-level downtime reported

Outcome

All 37 service-component migration items completed across application hosting, Functions, storage, secrets, workflows, communications, and supporting services, with critical dependencies and external integrations restored in the destination environment and no significant program-level downtime reported. The more durable result is the pattern: provisioning, networking, securing, deploying, and validating Azure application infrastructure now follows a sequence that has been run end to end rather than reasoned about.

My role

I led the application-infrastructure workstream within the wider migration program, as its project owner and hands-on engineer: the dependency inventory, the split into application, function, storage, secret-management, workflow, communication, and supporting-service tracks, the provisioning and reconfiguration of compute, storage, Key Vault, and identity, the development and production deployments, the CI/CD retargeting, the network attachment, the restored connections to databases, partner endpoints, messaging platforms, and file-transfer providers, and the staged cutover and validation.

What moved, as a dependency stack The migrated estate read as a stack of dependencies. Ten application compute workloads — five app and container services and five function apps — sat on top. Below them, six Logic Apps for workflow automation; then shared services, eight storage accounts and two communication services; then eight Key Vaults and three supporting services for secrets and identity; then the hub-and-spoke network, CI/CD, and monitoring. External integrations — the HR platform, file transfer, and partner APIs — sat outside the subscription at the foot. The four middle tiers account for all thirty-seven migrated components. App + container services 5 services, 5 function apps Workflow automation 6 Logic Apps Shared services 8 storage, 2 communication Secrets + supporting 8 Key Vaults, 3 supporting Networking + operations Hub-and-spoke VNet, CI/CD External integrations HRMS, SFTP, partner APIs depends on
Each arrow reads “depends on”, which is the order things had to move in. The four middle tiers add up to all 37 components; the dashed row at the foot sits outside the subscription and was the one thing the move was not allowed to change.
Technology
Azure App Service Azure Container Apps Azure Functions Logic Apps Azure Key Vault Azure Storage Azure Service Bus Managed Identity Hub-and-Spoke VNets Azure Communication Services Application Insights CI/CD