The Backend Stack: TypeScript or Nothing, CDK or Bust, DynamoDB All the Way

01AWS Was Never a Question

Years of experience with AWS before TCTF made the cloud platform decision trivial. There was no evaluation of Azure or Google Cloud Platform. There was no comparison matrix. AWS was the default because the team had deep expertise with its services, understood its pricing model, and knew how to operate production workloads on it.

The AWS ecosystem for serverless is unmatched. Cognito handles authentication with user pools, social sign-in, and multi-factor authentication. Lambda provides compute that scales to zero and charges per invocation. DynamoDB offers single-digit millisecond latency with pay-per-request pricing. S3 stores files with eleven nines of durability. SNS and SQS handle messaging with fan-out and queue-based processing. API Gateway routes HTTP requests to Lambda functions with built-in throttling and authentication. CloudWatch provides monitoring, logging, and alerting. X-Ray traces requests across service boundaries.

Each of these services integrates natively with the others. Lambda reads from DynamoDB over HTTP with SDK-level connection reuse — no RDS Proxy, no max connection limits, no connection exhaustion under high concurrency. API Gateway invokes Lambda without a proxy server. SNS triggers Lambda without a message consumer. CloudWatch monitors Lambda without an agent. The integration is seamless because the services are designed to work together.

The depth of the AWS ecosystem means we rarely need third-party services. Authentication, compute, storage, messaging, monitoring, tracing, DNS, CDN, secrets management — AWS provides all of them. The fewer external dependencies, the fewer integration points, the fewer vendors to manage, and the fewer bills to reconcile.

Azure and GCP are excellent platforms with their own strengths. But switching cloud providers is not like switching libraries — it is a fundamental architectural change that affects every service, every deployment pipeline, and every operational procedure. When you have years of experience with a platform and it meets your requirements, the right decision is to use it.

☁️

Years of AWS experience made the cloud decision trivial. Cognito, Lambda, DynamoDB, S3, SNS/SQS, API Gateway, CloudWatch, X-Ray — the serverless ecosystem is unmatched, and every service integrates natively with the others.

02TypeScript or Nothing: The Decision That Unified Everything

Being a Java developer for many years, this decision should have been simple. Java has Lambda support, mature libraries, strong typing, and a massive ecosystem. It is a proven language for backend services. The case for Java was strong on paper.

But TypeScript runs everywhere. Lambda functions are written in TypeScript. CDK infrastructure is written in TypeScript. React components are written in TypeScript. Test suites are written in TypeScript. Build scripts are written in TypeScript. One language for the entire stack means zero context switching. A developer reading a Lambda handler can immediately understand the CDK stack that deploys it and the React component that calls it.

This is not just a convenience — it is an architectural advantage. When the backend, the infrastructure, and the frontend share a type system, types flow through the entire stack. The OpenAPI spec generates TypeScript types that are used in Lambda handlers, the API client, and React components. A type error in any layer is caught by the same compiler. A field rename propagates through every layer with compiler assistance.

The TypeScript-everywhere decision shaped every subsequent technology choice. CDK won over Terraform because CDK is TypeScript and Terraform is HCL. Next.js won over alternatives partly because it is a TypeScript-first framework. The shared utility library is TypeScript. The test framework is TypeScript. The CI/CD scripts are TypeScript. Every tool that supports TypeScript gets a bonus point in evaluation because it reinforces the unified stack.

Java would have been a fine choice for the backend in isolation. But TCTF is not a backend — it is a platform with 34 backend services, 3 frontend applications, infrastructure-as-code, shared libraries, and build tooling. TypeScript is the singular decision that unified all of these into a coherent system. It is the decision that made every other decision easier.

🏆

TypeScript runs everywhere: Lambda, CDK, React, tests, build scripts. One language, zero context switching. This is THE decision that shaped everything else — CDK over Terraform, the shared type system, the unified developer experience.

03The IaC Journey: From Serverless Framework to CDK

Infrastructure-as-code was the decision that took the longest to settle. We evaluated seven tools before landing on CDK, and the journey through each one taught us what we actually needed.

Serverless Framework was the first attempt. It is popular, well-documented, and gets you from zero to deployed Lambda function quickly. But it is too opinionated — the abstraction layer hides AWS details that we needed to control. The YAML configuration becomes unwieldy for complex deployments. The plugin ecosystem is fragile, with plugins that break across versions and conflict with each other. For a simple Lambda API, Serverless Framework is excellent. For 34 services with complex IAM policies, custom resources, and cross-stack references, it is a constraint.

Claudia was too simple. It handles Lambda deployment well but does not manage the surrounding infrastructure — API Gateway configuration, IAM roles, DynamoDB tables, SNS topics. For a project that needs to manage the full infrastructure stack, Claudia is insufficient.

SST was promising. It builds on CDK with higher-level constructs and a live development environment. But at the time we evaluated it, SST was immature — breaking changes between versions, documentation gaps, and abstractions that did not match our deployment model. SST has improved significantly since then, but the timing was wrong for us.

SAM (Serverless Application Model) was the closest miss. It is AWS-native, handles Lambda packaging well, and integrates with CloudFormation. For simple Lambda applications, SAM is excellent. But for complex multi-service architectures with shared resources, cross-stack references, and custom constructs, SAM's template syntax becomes limiting.

Terraform is powerful and cloud-agnostic. But HCL is another language to learn, which violates the TypeScript-everywhere principle. Terraform's state management adds operational complexity. And cloud-agnosticism is not a benefit when you are committed to AWS — it is an abstraction layer that adds complexity without adding value.

CloudFormation is the foundation that CDK compiles to. Writing CloudFormation directly in YAML or JSON is painful at scale — no loops, no conditionals, no abstractions, no type checking. It is the assembly language of AWS infrastructure.

CDK is TypeScript. That alone would have been sufficient reason to choose it. But CDK also provides loops, conditionals, abstractions, composition, and the full power of a programming language for defining infrastructure. Custom constructs encapsulate patterns. Type checking catches configuration errors at compile time. The same IDE, the same linter, and the same testing framework that we use for application code work for infrastructure code. CDK was the winner because it is TypeScript, and TypeScript is everything.

🛤

️ Seven IaC tools evaluated: Serverless Framework → Claudia → SST → SAM → Terraform → CloudFormation → CDK. CDK won because it is TypeScript — same language, same IDE, same type system as everything else in the stack.

04DynamoDB or Nothing: Why NoSQL Won on AWS

We considered MySQL (via RDS) and PostgreSQL (via Aurora). Both are excellent databases with decades of proven reliability, rich query languages, and mature tooling. The case for a relational database was strong — TCTF has relational data (users have projects, projects have members, members have roles). SQL would have been a natural fit for the data model.

But on AWS with Lambda, DynamoDB is the natural fit for operational reasons that outweigh the data modeling convenience of SQL. The first reason is connection management. Lambda functions are ephemeral — they spin up, handle a request, and may be destroyed. Relational databases use persistent connections, and Lambda's ephemeral nature creates connection pooling problems. RDS Proxy mitigates this but adds cost, latency, and another component to manage. DynamoDB uses HTTP-based requests — no connections, no pooling, no proxy.

The second reason is latency. DynamoDB provides consistent single-digit millisecond latency regardless of table size. For a platform where API response time directly affects user experience, predictable latency is more valuable than flexible querying.

The third reason is pricing alignment. DynamoDB's pay-per-request pricing matches Lambda's pay-per-invocation model. When traffic is low, costs are low. When traffic spikes, both Lambda and DynamoDB scale automatically without provisioning. The pricing models are aligned, which means cost scales linearly with usage.

The fourth reason is operational simplicity. DynamoDB is fully managed — no patching, no backups to configure, no replication to set up, no failover to test. The operational overhead is zero. For a small team managing 34 services, zero operational overhead per database is the difference between manageable and overwhelming.

The tradeoff is the learning curve for single-table design. DynamoDB does not have JOINs, so related data must be modeled in a single table with carefully designed partition keys and sort keys. Access patterns must be known upfront. The data modeling is harder than SQL. But the operational simplicity — no connections, predictable latency, aligned pricing, zero ops — is worth the upfront investment in data modeling.

💾

DynamoDB over MySQL/PostgreSQL: no connection pooling issues with Lambda, single-digit millisecond latency, pay-per-request pricing aligned with Lambda, and zero operational overhead. The learning curve for single-table design is steep, but the operational simplicity is worth it.

05The Almost-WordPress Disaster

Early in the project, WordPress was seriously considered for the public portal. The reasoning was sound on the surface: WordPress powers over 40% of the web. It has thousands of plugins for every conceivable feature. It can be deployed quickly. Content management is built in. The team could have a public-facing website in weeks instead of months.

But TCTF is not a blog. It is not a marketing site. It is not a content management system. TCTF is a platform with authentication, social features, real-time messaging, project management, billing, contributor tracking, governance tools, and 34 backend services. WordPress would have handled the blog and the marketing pages. Everything else would have required plugins, custom PHP code, or external services bolted onto WordPress.

The plugin ecosystem that makes WordPress attractive for simple sites becomes a liability for complex platforms. Plugins conflict with each other. Plugin updates break functionality. Security vulnerabilities in plugins are a constant concern. The more plugins you add, the more fragile the system becomes. For a platform that needs to be reliable, secure, and maintainable, a plugin-dependent architecture is a risk.

The performance characteristics of WordPress are also wrong for a modern platform. WordPress generates pages on the server with PHP, which means every page load hits the database. Caching helps but adds complexity. The frontend is server-rendered HTML with jQuery-era JavaScript. Building a modern, interactive UI on top of WordPress requires fighting the platform rather than working with it.

The decision to build custom with Next.js and Lambda was harder upfront. It meant building the blog, the marketing pages, and the content management from scratch instead of getting them for free with WordPress. But it also meant that the public portal, the social network, and the backend services all share the same technology stack, the same deployment pipeline, and the same development workflow. WordPress would have been a dead end — a CMS trying to be an application platform, accumulating technical debt with every plugin and custom hack.

The almost-WordPress disaster is a reminder that the easiest short-term decision is often the most expensive long-term decision. WordPress would have saved months at the start and cost years in the long run.

⚠️

WordPress was seriously considered. It would have handled the blog but nothing else. TCTF is a platform with 34 services, not a CMS. The easiest short-term decision would have been the most expensive long-term decision.

06The December 2025 Rewrite: From Monolith CDK to Microservices

The original CDK setup deployed all backend code as a single CloudFormation stack. One CDK app, one stack, all 34 services. This was the fastest way to get started — define all Lambda functions, DynamoDB tables, API Gateway routes, and IAM roles in one place, deploy with one command, and everything is up and running.

The problem became apparent as the number of services grew. A change to one Lambda function triggered a CloudFormation update that evaluated every resource in the stack. The deployment took 20-30 minutes. A failed deployment rolled back everything, not just the changed service. The blast radius of any change was the entire platform.

Worse, the single-stack approach created coupling between services that should have been independent. Circular dependencies between resources prevented clean separation. IAM policies were broader than necessary because resources shared a stack. The deployment order was determined by CloudFormation's dependency resolution, not by business priority.

The entire December was spent rewriting the CDK to manage each service as an independent stack with its own deployment pipeline. This meant extracting each service's Lambda functions, DynamoDB tables, API Gateway routes, and IAM roles into a separate CDK app. Cross-service references were replaced with SSM parameters and CloudFormation exports. Shared resources (like the Cognito user pool) were moved to a shared infrastructure stack that other stacks reference but do not modify.

The rewrite was painful. Rewriting working infrastructure is never fun. Every extraction risked breaking a service that was already running in production. The testing was meticulous — deploy the new stack, verify it works, switch traffic, decommission the old resources. For 34 services, this process took the entire month.

But the December rewrite was the moment the architecture became real. Before the rewrite, TCTF had a distributed monolith — services that were logically independent but operationally coupled through a shared deployment. After the rewrite, each service deploys independently, scales independently, and fails independently. A bad deployment to the user service does not affect the billing service. A traffic spike on the messaging service does not require redeploying the project service. This is what microservices actually means — not just separate code, but separate deployments, separate scaling, and separate failure domains.

🔨

The December 2025 rewrite: one month of extracting 34 services from a single CDK stack into independent stacks. Painful, but it was the moment the architecture became real — not a monolith pretending to be microservices, but genuinely independent services.