Lee D. — Freelance Infrastructure & Backend Architect

01 — Expertise

Define the problem, solve it with structure

infrastructure

Infrastructure Design

What problems I tackle

Things slow down under load, one component's failure cascades to everything, and nobody knows where the cloud bill goes. The bigger the scale, the more the structural debt shows.

How I approach them

I map failure propagation paths first, then split the system along isolation boundaries. Everything is codified as IaC for reproducibility, with observability that puts cost and performance on the same screen.

what i can deliver

Multi-AZ redundancyZero-downtime deploysAutoscaling policy designIaC standardizationCloud cost optimization

backend

Backend Design

What problems I tackle

Features keep growing but the code is entangled — fix one thing and another breaks. When deploys start feeling scary, it's time to revisit the design.

How I approach them

Define domain boundaries first; boundaries communicate only through explicit API contracts and async messaging. The goal is a structure where teams ship without waiting on each other.

what i can deliver

API contract designEvent/queue-based async processingIdempotency & retry designIncremental legacy extractionLoad testing

database

DB Optimization

What problems I tackle

One screen is inexplicably slow, overnight batches collide with daytime traffic, lock contention causes timeouts. Most of the time it's the access pattern, not the query.

How I approach them

Pin the bottleneck down with numbers — execution plans and slow-query logs — then intervene in order: indexes, schema, cache layer. Before/after is always compared on the same metrics.

what i can deliver

Slow-query diagnosisIndex & execution-plan tuningRead/write separationPartitioning & shardingZero-downtime migrations

apm / observability

APM & Monitoring

What problems I tackle

When something breaks, finding the cause takes longer than fixing it, and everyone agrees it's slow but nobody can say where. Without metrics you can't even prove an improvement happened.

How I approach them

Request-level tracing and the key metrics go in first, so bottlenecks become visible. Dashboards are built around what each owner actually needs to see, and alerts are trimmed to conditions that genuinely require a response.

what i can deliver

Distributed tracing rolloutSLI/SLO definitionDashboard designAlert-rule cleanupIncident post-mortems

02 — Architecture

Architecture where the intent shows

Under NDA the projects can't be named, so only the anonymized structure remains. The outcome figures live in the cases below — this section shows why each structure was chosen.

diagram a — write buffering

Web

Mobile

Partner API

CDN / WAF → API Gateway

App Service ×N auto-scale

Message Queue buffer

Worker Pool ×N

Primary DB

Object Storage

case A — traffic spike

Why a queue instead of more servers

There were three options — more instances, a bigger connection pool, or a queue. Scaling up buys a five-minute peak with an always-on bill; a bigger pool just forwards the pressure to the DB. Separating intake from processing was the smallest change that would hold the longest, with worker consumption as the throttle. Traffic has grown since; the structure hasn't moved.

See the related case

diagram b — read / write split

Application

Data Access Layer routing

Cache

hot path

Read Replica ×2

reads

Primary DB

writes

index rebuilt on execution planno schema change

case B — query latency

Why the schema stayed and only the access layer changed

A schema redesign is the textbook answer, but the migration risk and the team's operating burden outweighed the gain. Splitting reads onto a cache and replicas and rebuilding indexes against real execution plans was judged enough to hit the latency target — and it was. Every change made was reversible; that was the point.

See the related case

03 — Cases

Results, in numbers

Most work comes through referrals, so the volume is modest. Client names can't be disclosed, so only sector and scale are noted.

Not the best possible design — the one this team can run

Drop an architecture built for tens of millions of requests onto a three-person team and in six months nobody can touch it. I check traffic, headcount, and budget first, then propose whatever survives longest inside those limits.

With no ops staff, managed services come first. Self-run Kubernetes is not always the answer.
Scalability you don't need yet doesn't get built — only the boundaries to swap it in later.
We agree up front where cost matters more than performance, and design for savings if that's the goal.
Documentation and handover are part of the deliverable, so the team keeps running it after I leave.

Selected work

E-commerceMar – May 2026 · 8 weeks·4 backend devs · no infra owner Order processing buckling under promotion traffic — solved without adding servers 40×peak absorbed

Situation

A commerce service with 5M+ MAU. For a few minutes after each promotion opened, traffic hit dozens of times its normal volume, causing checkout timeouts and duplicate orders. There was no dedicated infra engineer; four backend devs handled both features and operations.

Intervention

I proposed separating intake from processing — one queue stage plus idempotency keys. The team applied it; I stayed on through PR review and pairing. No microservice split, no event sourcing — the smallest change this team could keep maintaining came first. The trade-off, agreed up front: when the queue backs up, order confirmation lags by a few seconds.

Result

The next promotion passed with no lost orders and checkout p95 held at 1.2s. No extra instances, and no new component to operate.

stack usedAWS SQSECSAurora MySQLRedisTerraform

Finance / SettlementSep – Nov 2025 · 10 weeks·6 devs · 1 DBA Nightly settlement batch no longer spilling into daytime traffic 6h → 40mbatch window

Situation

A system settling 20M transactions a day, where the batch didn't finish overnight — overlapping daytime traffic and slowing service queries through lock contention. There was no budget for a new system, and the existing schema had to stay.

Intervention

I proposed replacing full recomputation with incremental processing and partition-parallel aggregation; the team applied it with my reference implementation and reviews. Batch reads moved to a dedicated replica, with no schema change. Batches outside settlement were left alone.

Result

The settlement batch went from six hours to forty minutes and the delay alerts stopped. Handover docs and a reproducible run procedure were left with the team.

stack usedPostgreSQLSpring BatchRead ReplicaPartitioning

Media / ContentFeb – Mar 2025 · 5 weeks·3 devs · no ops owner An infrastructure rebuild where cost reduction was the goal -34%monthly cost

Situation

A service peaking at 80K concurrent users. Far more instances were permanently provisioned than traffic justified, and the list API ran uncached. With nobody on ops, they needed a setup that demanded less attention, not a better one.

Intervention

I proposed rebuilding autoscaling policies on managed services instead of introducing Kubernetes. The team moved list reads behind a cache and retired idle resources; we pinned the final setup in IaC together.

Result

Monthly cloud spend fell 34% and list API p95 dropped to a third. The only new thing to operate was a single cache.

stack usedAWSCloudFrontElastiCacheTerraformAuto Scaling

Short & spot engagements

Jul 2026 · 3 daysSaaS / B2B A three-day review that replaced a rewrite with two targeted fixes Node.jsPostgreSQLRedisGrafana 3 days

Jan 2026 · 1 weekStartup / Seed MVP architecture advisory — start with a monolith, not microservices Node.jsPostgreSQLAWS 1 wk

Dec 2025 · 4 daysStartup / Series A Pre-due-diligence architecture check with documented risks Architecture reviewCost analysisSecurity check 4 days

Jun 2025 · 2 daysHealthcare / Early Pre-launch DB schema review — indexes and normalization sorted out MySQLSchema design 2 days

* All figures are rounded and generalized to what the contracts allow.

nda & confidentiality

Confidentiality comes before the contract

Every engagement so far has run under an NDA, and this page contains no client names, service names, real schemas, code, or raw figures anywhere. The diagrams keep the structure and drop everything identifying; the metrics are generalized to what may be disclosed.

I sign on your NDA template. If you don't have one, I propose a standard NDA before anything starts.
Deliverables and access credentials are returned or destroyed at the end of the engagement — no copies left in my own environment.
Other clients never come up in an identifiable form, not even in conversation.

04 — How I Work

I design it; your team runs it

Working solo means I don't operate client infrastructure day to day. I diagnose the problem, design the structure, hand it over in a form the team can apply, and review alongside them while they do. The goal is a system the team can still run after I leave.

01

Diagnose

Metrics, logs, code, and the team's situation, written up as bottlenecks and constraints. Typically three days to two weeks.

02

Design & propose

Two or three options, each with its cost, headcount, and risk. The options I don't recommend are written down too, with reasons.

03

Support the rollout

Your team makes the changes; I attach through PR review, pairing, and decision support, with reference implementations where needed.

04

Hand over

Diagrams, runbooks, and monitoring baselines stay as documents. Questions stay answered for a while after the engagement ends.

What I do

Architecture diagnosis & design
Prioritized improvement plan
PR review & pairing
Reference implementation & load tests
Documentation & handover

What I don't

Day-to-day operations & on-call
Hands-on access to your infrastructure
Staff-augmentation seat filling
Sole ownership of long-term maintenance

05 — Tech Stack

Tools chosen to fit the problem

This list is trimmed to what actually informs design decisions. Core and adjacent are marked separately — adjacent means enough depth to work with the team that owns it. Seeing what a screen calls and what a device sends — and how often — with the same lens helps on the calls you can't make from the server side alone.

Cloud

cloud·core

AWSECS / EKSAuroraSQS · ElastiCacheLambdaCloudFrontGCP

Backend

backend·core

Node.js / NestJSSpring BootGoKafkagRPC

Database

database·core

MySQL / AuroraPostgreSQLRedisMongoDBElasticsearch

Infra Tools

infra tools·core

TerraformDockerKubernetesGitHub ActionsNginx

Monitoring & APM

monitoring·hands-on

DatadogOpenTelemetryGrafanaPrometheusSentry

Frontend

frontend·adjacent

TypeScriptReactNext.js

Embedded & Firmware

embedded·adjacent

C / C++MCU firmwareRTOSMQTT · BLE

06 — Get in Touch

Have a problem worth solving together?

A short note about what you're running into is enough to start. Even if the requirements aren't settled yet, working out what the system actually needs is part of the job. Engagements start as small as a three-day review.

Send an email