Anonymized client work / Identifying details removed

Multi-source content platform

Greenfield Serverless Build
Case Study

Built from an empty repository

AWS: Lambda + DynamoDB + API Gateway

Multi-source aggregation, multi-language

Engagement
Greenfield cloud-native platform, designed and built from zero
My work
Architected and led the backend core: Lambda and DynamoDB application design, content-sync pipelines, search, cart, admin, APIs, and the MCP interface
System scope
AWS application core, Terraform infrastructure-as-code, CI/CD, an AI/MCP interface, and a containerized download proxy, delivered within a small team
Evidence boundary
The technology is real; the client, providers, and business domain are generalized. My role and the team attribution were confirmed for publication. AI chat and parts of the base infrastructure were built by teammates.

These labels describe how the public claims are supported. Confidential source material remains private.

  • Verified

    The repository supports the architecture and implementation facts: Lambda, DynamoDB, API Gateway, Cognito, S3, CloudFront, Terraform infrastructure-as-code, CI/CD, aggregation pipelines, search, cart, admin, and the MCP interface.

  • Reported

    I confirmed for publication that I architected and led the backend core, while teammates built the AI chat and parts of the base infrastructure.

  • Inferred

    The on-demand application core reduces standing capacity for its request and ingestion paths. The large-file proxy is containerized, and no spend, traffic, uptime, or whole-system cost result is claimed.

One searchable catalog, built from an empty repository.

The platform aggregates content from several external providers into a single, multi-language catalog with search, a shopping cart, and an AI-assisted discovery interface. Its application core uses AWS Lambda, DynamoDB, and API Gateway behind Cognito, with Terraform infrastructure-as-code and CI/CD from the first commit. A separate containerized proxy handles large-file delivery. I architected and led the backend core; AI chat and parts of the base infrastructure were built by teammates.

Starting pointGreenfield - empty repository
Application coreLambda + on-demand DynamoDB
FoundationTerraform IaC + CI/CD from day one

A multi-source platform, from providers to catalog

ClientsWeb + mobileCatalog + cart EdgeAPI Gateway+ Cognito auth Application coreAPI Lambdassearch - cart - admin - MCP DataDynamoDBon-demand tables SourcesExternal providersprovider feeds IngestionSync Lambdasper-source into one catalog Large filesS3 + CloudFront+ container proxy On-demand application core: Lambda + DynamoDB Terraform infrastructure-as-code + CI/CD from the first commit

What changed: Requests flow from clients through API Gateway and Cognito into API Lambdas that read and write an on-demand DynamoDB catalog. In parallel, per-source sync Lambdas ingest external providers into that catalog. These application paths run on demand, while S3, CloudFront, and a separate containerized download proxy support large-file delivery.

4 initiatives changed the operating model.

I-01 / On-demand application core

Match core capacity to request and ingestion demand

BeforeThe application needed to support variable request and ingestion load without starting from a fixed application-server fleet.

Why it matteredA standing fleet would introduce idle capacity, patching, and capacity-planning work before the product had stable demand.

InterventionBuilt the application core on AWS Lambda with on-demand DynamoDB and API Gateway behind Cognito. Large-file delivery remained an explicit containerized proxy boundary.

I-02 / Aggregation pipelines

Turn many external sources into one catalog

BeforeContent lived across several external providers with different shapes, languages, and update cadences.

Why it matteredWithout a common model, every provider would leak its quirks into the product and search would be inconsistent.

InterventionBuilt a per-source sync Lambda for each provider that normalizes into a single catalog, with sync progress and admin controls, so adding a source extends one pipeline pattern rather than introducing another system.

I-03 / Search and languages

Make a multi-language catalog searchable

BeforeThe catalog spans multiple languages, including macrolanguage relationships that naive matching gets wrong.

Why it matteredUsers searching in their own language needed to find relevant content without knowing how providers labeled it.

InterventionBuilt search over the aggregated catalog with explicit language and macrolanguage handling, plus a cart and an MCP interface so the catalog is reachable by both people and agents.

I-04 / Foundation from day one

Reproducible infrastructure, not a hand-built environment

BeforeA greenfield project created the opportunity to establish the delivery foundation before product dependencies accumulated.

Why it matteredSkipping infrastructure-as-code and CI/CD early would make later changes slower and environments harder to reproduce.

InterventionDefined the stack in Terraform with a CI/CD pipeline and plan review, managed authentication through Cognito, and supported large-file delivery through CloudFront, S3, and a containerized download proxy.

An on-demand core with an explicit container boundary.

The application core uses Lambda and on-demand DynamoDB for request and ingestion paths, while the containerized download proxy remains visible as a separate operational boundary. A new content source follows the same sync-Lambda pattern into the shared catalog. The stack is defined in Terraform and delivered through CI/CD. No spend, traffic, uptime, catalog-size, or whole-system cost result is claimed.

OperationsOn-demand application core; container proxy isolated for large files
ExtensibilityA new source follows the same sync-Lambda pattern into the catalog
FoundationStack reproducible via Terraform + CI/CD

Foundation first, then pipelines, then product surfaces.

  1. Step 01Lay the foundation

    Terraform infrastructure-as-code, API Gateway with Cognito authentication, on-demand DynamoDB, and a CI/CD pipeline with plan review.

  2. Step 02Build the aggregation

    A per-source sync Lambda for each provider that normalizes into a single catalog, with sync progress and admin controls.

  3. Step 03Make it discoverable

    Search across the catalog, multi-language and macrolanguage handling, and a shopping cart.

  4. Step 04Deliver large files and open an agent interface

    CloudFront, S3, and a containerized download proxy for large-file delivery, plus an MCP interface so agents can reach the catalog.

Make reliability
an operating property.

Describe the fragile workflow