Architectures I've designed and run
Layered diagrams of the platforms behind my case studies, with every service named. They show how I work as a solution architect, system designer, DevOps engineer, SRE and cloud engineer.
How to read the diagrams
- Top to bottom: users and devices first, then edge, compute, data, delivery, and security and observability. Colour marks the kind of service. Moving dashes show the direction of requests or data.
- A dashed outline means planned, in progress or proposed, so nothing here claims more than is in place. Client platforms are anonymised.
Patterns I design with
- Serverless and event-driven: Lambda behind API Gateway, SNS FIFO to SQS fan-out, and CDC-driven ingestion from a legacy database (the strangler pattern).
- Multi-tenant SaaS: tenant-isolated data, delegated admins and per-tenant metrics (Remotely, Outpace).
- Real-time systems: WebSockets with a connection registry, Redis pub/sub with Streams replay (HospitalHub, Remotely).
- Zero-trust access: outbound-only agents, just-in-time credentials and a tamper-evident audit log (Remotely).
- Infrastructure as code and gated delivery: Terraform and CDK, manual-trigger production deploys, rollback by re-tagging an image.
- Resilience and DR: read/write splits, a warm-standby design with drill-tested failover (proposed), backups taken and checked before any deletion.
Freight and logistics operations platform
The operations backbone of a US less-than-truckload carrier: dispatch and live driver tracking, linehaul planning, inbound operations, quoting and billing, and a customer portal. Staff use a micro-frontend web app, drivers an Android app with face-recognition login, and customers a self-service portal. Behind them sit serverless services and a data platform that replicates a legacy on-premises database into AWS.
Layers run from users at the top down to delivery and security. Dashed ghost tiles are planned or proposed, not built.
Hover a service for 3 seconds, or click it, to see its details in the corner panel. Esc closes it.
- Edge
- Identity
- Compute
- Data
- Messaging
- Delivery
- Security / ops
- External
- Proposed, in progress or not yet wired
- Request or data flow
- Replication or CDC
- 1
Clients reach the edge
Office staff load the web shell from CloudFront and its S3 origin, and its five micro-frontends are registered at runtime. Drivers, customers and sales staff call API Gateway. Route 53 and ACM provide DNS and certificates. The CDK also defines an Amplify app, and which stage uses which web host is still to be confirmed.
- 2
Identity
Cognito issues tokens from three pools: staff through SAML federation, drivers through a custom challenge backed by Rekognition face matching (with no liveness check), and customers with just-in-time migration of legacy passwords.
- 3
Authorise, then invoke
API Gateway runs a shared Lambda authorizer. It verifies the JWT, checks a maintenance flag in DynamoDB and looks up role permissions in PostgreSQL through RDS Proxy, then returns an IAM policy. The cache TTL is 0, so every request reaches the database.
- 4
Database access
API Lambdas reach Aurora through RDS Proxy over TLS with credentials from Secrets Manager. The back-office and linehaul APIs split reads and writes: GET requests use the read-only endpoint. Prod has a writer and two readers, with readers autoscaling from two to five.
- 5
Events
The driver backend, linehaul API and inbound-operations API publish to a FIFO SNS topic, which filters by event type into SQS queues for notifications, database sync, telematics and logging. Location pings arrive over a WebSocket and land in DynamoDB tracking tables. Scheduled jobs run from EventBridge.
- 6
Strangler modernisation
DMS replicates the on-premises DB2 system of record into a legacy-mirror Aurora cluster. Sixteen database trigger functions invoke a publisher Lambda, which routes each change to one of five entity queues. Processors write the modern schema in the operations Aurora and also write back to DB2. The three writes are not one distributed transaction.
- 7
Analytics and partner access
DMS also feeds Redshift and a BI Aurora cluster. Three internet-facing network load balancers, limited by an IP allow-list, give BI, CRM, fleet and planning tools database access. A DMS to S3 data-lake target is defined but unused.
What I did here
- Audited all 15 repositories read-only and corrected documentation that contradicted the code, including a database documented as global that had no secondary region attached.
- Led the active/active feasibility study: 13 blockers ranked, and a recommendation of warm standby over multi-master (proposed targets: RPO about 1 second, RTO 1–15 minutes). The dashed items are that proposal. It is a design, not a running system.
- Analysed the non-production account's cost: 38 recommendations worth about 30% of its forecast month-end cost. These are recommendations; I have no confirmation they were applied.
- Wrote the root-cause analysis for a deploy outage caused by the IAM role quota, and audited the roles read-only. The clean-up is still open.
- Wrote the architecture documentation: one 15-section design template across eight services, plus handbooks, runbooks and a beginner's guide.
Every service, by layer
| Layer | Services |
|---|---|
| Clients | Office web app (React 18, TypeScript, Vite Module Federation), Android driver app (Flutter), customer portal, sales micro-frontend, BI and partner tools |
| Edge and identity | Route 53, ACM, CloudFront, API Gateway (REST, HTTP, WebSocket), Cognito (staff SAML federation, driver custom challenge, customer just-in-time migration), Rekognition |
| Compute | Lambda: Python FastAPI with Mangum, .NET 8 ASP.NET Core with EF Core, Dapper and MediatR, Node.js authorizers, a 54-function driver mobile backend, CDC ingestion processors |
| Messaging | SNS FIFO, SQS FIFO with dead-letter queues on some queues, EventBridge, DynamoDB (13 tables) |
| Data | RDS Proxy, Aurora PostgreSQL (operations, legacy mirror, BI), DMS, Redshift, Glue, on-premises DB2 |
| Delivery | AWS CDK (Python and TypeScript), CDK Pipelines, GitHub Actions, Android over-the-air code push, a feature-flag service |
| Security and observability | Secrets Manager, KMS on selected stores, CloudWatch, X-Ray, SAST nightly in most repos, Cost Explorer, Cost Optimization Hub, Cost Anomaly Detection |
Read the full case study: audit, documentation and multi-region feasibility →
Tax-services SaaS
A US tax-services marketplace and practice-management SaaS: taxpayers find tax professionals, and professionals get CRM, invoicing, e-signature and an accounting sync. An AI assistant answers tax questions over a Weaviate vector database fed with current tax information. I lead DevOps for the whole estate.
Layers run from users at the top down to delivery and security. Dashed ghost tiles are planned or in progress.
Hover a service for 3 seconds, or click it, to see its details in the corner panel. Esc closes it.
- Edge
- Identity
- Compute
- Data
- Messaging
- Delivery
- Security / ops
- External
- Proposed, in progress or not yet wired
- Request or data flow
- Replication or CDC
- 1
Browsers reach the web app
Taxpayers and tax professionals resolve through Route 53 to the App Runner web service, which terminates TLS itself. CloudFront fronts only the S3 content buckets, not the apps.
- 2
Sign-in goes through the API
The browser calls the NestJS API, which uses Cognito admin APIs. The API accepts Cognito-issued JWTs or its own signed token. The frontend does not use a Cognito SDK.
- 3
The API reads and writes data
The API uses PostgreSQL through two ORMs and a MongoDB connection. Uploads go straight from the browser to S3 with presigned URLs. A cron service, the same image with a flag, runs 27 scheduled jobs.
- 4
AI answers
The API calls a private API Gateway route with an API key. A Lambda runs relevance checks, embeds the question, searches Weaviate and asks the LLM, with a web-search fallback and a 180-second timeout. Voice and dictation use short-lived realtime tokens.
- 5
Queues carry the heavy work
The API publishes warehouse updates to a FIFO queue. The event processor stores 19 event types in the document database and invokes the recommendation generator. PDF jobs use their own queue and a headless-browser worker. Accounting sync uses a third queue that the API itself polls.
- 6
Third parties
Webhooks arrive at public API routes, verified by signature or HMAC. Payments, e-signature, accounting, chat and the filing partner each have one. Outbound calls cover the LLM, maps, OCR and the filing partner.
- 7
Delivery and observability
GitHub Actions builds images into ECR and, for production, runs only on a manual dispatch; the re-tag rollback uses the same registry. Terraform holds the monitors, the tax engine and the temporary test environment. Datadog monitors, SLOs and dashboards are defined in Terraform.
What I did here
- Audited the environments (seven long-running and one temporary) and wrote the architecture deep dives, runbooks and a ranked findings register.
- Built gated GitHub Actions pipelines: staging deploys automatically, production deploys only on a manual trigger, and rollback re-tags an earlier image with no rebuild. I ran two production releases through them, the second on 8 October.
- Defined 70 monitors, 2 dashboards and 4 SLOs as code in Terraform, running in observation mode while thresholds were tuned from real traffic.
- Applied the infrastructure for a new tax-calculation service, rotated the production database credential and started a staged, reversible migration of staging from App Runner to ECS Fargate. The dashed boxes above mark what is still planned or in progress.
Every service, by layer
| Layer | Services |
|---|---|
| Edge and identity | Route 53, ACM, CloudFront (in front of S3 content), API Gateway (analytics and PDF APIs), Cognito; private database networking (NAT, VPC connector) is planned |
| Compute | App Runner (Next.js web, NestJS API, cron), ECS Fargate (tax engine behind an ALB, and the staging migration in progress), Lambda (ten analytics functions plus a PDF service) |
| Data | RDS PostgreSQL, managed MongoDB, managed Weaviate, S3, SQS FIFO queues with dead-letter queues; AWS Backup is planned |
| External | Payments, e-signature, accounting software, a tax-filing partner, chat and video, and an LLM provider (names withheld) |
| Delivery | GitHub Actions, Docker, ECR, Terraform, Serverless Framework, AWS SAM |
| Security and observability | Secrets Manager (staging first), a scoped production deploy user, Datadog, CloudWatch alarms and Synthetics, org CloudTrail; GuardDuty planned |
On-premises and hybrid: home lab
Where I practise on real infrastructure instead of theory. A Proxmox/KVM host sits behind pfSense and runs a 12 vCPU, 32 GB VM for Kubernetes and OpenShift work. The rest is a self-hosted toolset I use day to day, plus personal AWS and Azure accounts for hybrid practice.
Layers run from users at the top down to delivery and security. Dashed ghost tiles are planned or proposed, not built.
What I do here
- Run and break the same kinds of tools I look after at work: source control and CI, secrets management, documentation, asset tracking and backups.
- Practise Kubernetes and OpenShift with real errors. I have planned a nine-phase curriculum covering cluster bootstrapping, CNI and NetworkPolicy, GitOps, observability, security, chaos engineering and multi-cluster. It is a plan, not finished work.
Product architectures
The three products I built each have their own diagram on their case-study page.
Remotely: agents, control plane and access targets →
HospitalHub: modular monolith with PostGIS and Redis →
Outpace: Next.js on Graviton with a Terraform-built AWS stack →