CASE STUDY
CloudOps Content Platform
An Express.js headless CMS with SQL ownership, secure sessions, cache-aside reads and retryable activity delivery.
Problem & constraints
Provide product and content operations with draft, published and archived states, protected administrative workflows and public reads. Keep PostgreSQL authoritative while adding optional acceleration and asynchronous activity history. The repository defines AWS infrastructure; AWS provisioning and live verification remain pending.
Architecture & engineering decisions
React, TypeScript, Vite, React Router, TanStack Query, Context API and CSS separate routing, server state and UI state. Express.js REST routes delegate through controller, service and repository layers. PostgreSQL uses pg and raw SQL, making query shape, transactions and database behavior visible instead of hiding them behind an ORM.
Database & caching
Checksum-tracked migrations, transactions, connection pooling, indexing and EXPLAIN ANALYZE support relational operations. Redis uses cache-aside reads, TTL and invalidation with graceful database fallback. A cache outage should affect latency rather than replace PostgreSQL as the system of record.
Asynchronous processing & failure handling
Business changes and activity events enter a PostgreSQL transactional outbox together. A worker delivers append-oriented activity to DynamoDB with retry/backoff and idempotency. The delivery boundary must tolerate a crash after the external write but before acknowledgement. Cache invalidation and worker recovery are explicit application concerns.
Authentication & security
Session authentication uses HttpOnly cookies, CSRF protection, RBAC and scrypt password hashing. Zod validates requests; Helmet, rate limiting and configured CORS protect HTTP boundaries. Swagger / OpenAPI documents the API. Public content visibility is enforced in queries, not just frontend navigation.
Testing & performance
Frontend checks use Vitest and React Testing Library. Server tests cover service, API, persistence and security behavior. k6 workflows define smoke, load, stress and spike scenarios; database timing and Redis optimisation support investigation. Test tooling and scenarios do not constitute published performance results.
Observability & health
Structured JSON logs and request IDs support correlation. Prometheus-compatible metrics, OpenTelemetry, Grafana and CloudWatch configuration provide observability integration points. Separate /live and /ready health checks distinguish process liveness from dependency readiness; application routes include /api/v1/health/live and /health/ready.
Infrastructure implemented; deployment pending
Multi-stage Docker builds and Docker Compose support packaging and local operation. Terraform defines ECR, ECS / Fargate API and worker services, RDS PostgreSQL, DynamoDB, S3, CloudFront, ALB, VPC, IAM, Secrets Manager and CloudWatch. ECS autoscaling and horizontal service scaling are infrastructure patterns, not evidence of a running or load-validated AWS environment.
Roadmap / Planned delivery
GitHub Actions CI/CD is planned / being completed and is not represented as finished. AWS provisioning, live smoke verification and measured deployment/performance evidence remain next steps.
Lessons & next improvements
SQL ownership simplifies transactional reasoning, while cache and worker boundaries require explicit failure policies. Complete live infrastructure verification and CI/CD, then measure behavior under cache failures and worker restarts before making operational claims.