Serverless GraphQL API on AWS
AWS AppSync and Lambda serve a GraphQL API over DynamoDB, while DynamoDB Streams update an OpenSearch read model asynchronously.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasServerless GraphQL AWS architecture diagram with AppSync, Lambda resolvers, DynamoDB Streams, and OpenSearch. The image links to a fully editable BuildPlane starter.
Overview
Application clients send GraphQL operations to AWS AppSync, which invokes Lambda resolvers for domain logic. DynamoDB stores authoritative records and emits changes through DynamoDB Streams. A Lambda indexer converts those changes into an OpenSearch search projection.
Components
- AppSync and Lambda resolvers: AppSync exposes the GraphQL surface while Lambda handles domain-specific operations.
- DynamoDB and Streams: The table is authoritative and its stream emits ordered change records for downstream projections.
- Indexer and OpenSearch: A Lambda consumer builds a search-optimized read model without slowing synchronous mutations.
GraphQL and Indexing Flow
- Clients send GraphQL operations to AppSync.
- Lambda resolvers apply business rules and write authoritative records to DynamoDB.
- DynamoDB Streams invokes the indexer, which updates the OpenSearch read model.
Customize First
- Choose direct AppSync resolvers where Lambda adds no business value.
- Design stream retry and replay behavior so the search index can be rebuilt safely.
- Add Cognito or another supported authorizer with field-level access rules.
Design rationale
Decisions that shape this architecture
Put the GraphQL contract at AppSync
AppSync owns schema validation, authorization integration, resolver execution, and subscriptions instead of rebuilding those concerns in a generic HTTP service.
Keep DynamoDB authoritative
Mutations commit to DynamoDB first. Search remains an asynchronous projection that can lag or be rebuilt without becoming the source of transactional truth.
Index from the table stream
DynamoDB Streams decouples search indexing from client latency and preserves ordered item changes for retryable consumers.
Before production
Operational checks
Test schema authorization for every object, field, tenant, and mutation path.
Alarm on resolver errors, throttling, stream iterator age, and failed index updates.
Make the indexer idempotent and document a full search-index rebuild procedure.
Track GraphQL query complexity, latency, DynamoDB access patterns, and search freshness.
Scope and tradeoffs
What this diagram does not solve
Search is eventually consistent
A successful mutation can be visible in DynamoDB before the OpenSearch projection updates. The user experience must tolerate that delay.
Lambda is not always needed for every resolver
Direct AppSync resolvers may be simpler for straightforward data access. Keep Lambda only where domain logic or integration behavior justifies it.
Common questions
Frequently asked questions
Why use DynamoDB Streams for OpenSearch indexing?
The stream emits table changes asynchronously, allowing search documents to update without adding OpenSearch latency or failures to the mutation request.
Can AppSync call DynamoDB directly?
Yes. Direct resolvers can reduce cost and latency for simple access patterns. Lambda is useful when requests need richer domain logic or coordination.
How is the OpenSearch index rebuilt?
Use a controlled backfill from DynamoDB or an exported snapshot, then resume stream processing from a known checkpoint and reconcile missed updates.
Keep exploring
Related AWS architectures
Serverless REST API Architecture on AWS
This architecture is the smallest useful serverless API baseline: a managed HTTPS entry point, stateless function compute, on-demand data storage, and observable execution. It is intentionally compact so the first production decisions remain easy to see.
Explore the architecture
Generative AI RAG Assistant on AWS
This retrieval-augmented generation architecture separates the API contract, orchestration logic, owned knowledge, vector search, and foundation model. It provides a clear baseline for grounding model responses in private documents while keeping ingestion, evaluation, authorization, and conversation storage as explicit next decisions.
Explore the architecture
Serverless Multi-Tenant SaaS Architecture on AWS
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.