SYSTEM Cited by 9 sources
DynamoDB¶
Amazon DynamoDB is AWS's managed serverless key-value / document database. It's horizontally scalable by partition key, JSON-friendly, and commonly chosen when the workload needs fast single-item reads and writes at unbounded scale and you don't want to operate a sharding layer yourself.
Pattern of appearance¶
In system-design stories DynamoDB most often shows up as the scale-out replacement for a vertically-scaled OLTP store used as an event log or hot-write workload. The storage-scalability story is strong; the processing story is the same as any other OLTP store — per-record lookups are still per-record lookups.
Canva's Creators-payment counting pipeline used DynamoDB for this exact role: when MySQL RDS was doubling every 8–10 months, they moved raw usage events to DynamoDB to eliminate the storage growth problem. They explicitly chose not to move the rest of the pipeline onto DynamoDB, because the per-record database round-trip problem remains: running deduplication and aggregation over billions of events by reading each one is O(N) DB calls regardless of backend. Canva took this as a signal to move the processing into an OLAP engine (Snowflake), not just re-platform the OLTP layer. (Source: sources/2024-04-29-canva-scaling-to-count-billions)
Data shape notes¶
DynamoDB stores JSON-shaped items natively, which is ergonomic for event-producer code but not ideal for warehouse query performance. Canva's extract-load step into Snowflake projects the interesting JSON fields into typed SQL columns to make downstream GROUP BY / filter queries cheap — worth generalising: if DynamoDB is the upstream to an analytics workload, plan for a typed projection in the E/L.
Seen in¶
- sources/2024-04-29-canva-scaling-to-count-billions — DynamoDB as the raw-event store for Canva's counting pipeline, replacing MySQL for that tier; explicit decision not to move dedup/aggregation onto it because DB round-trips still dominate.
- sources/2024-07-29-aws-amazons-exabyte-scale-migration-from-apache-spark-to-ray-on-ec2 — DynamoDB as the durable job-lifecycle state store in Amazon BDT's 2021 serverless Ray job-management substrate (alongside systems/aws-sns, systems/aws-sqs, systems/aws-s3) — powering >1,600 Ray compaction jobs/day over exabyte-scale S3 tables.
- sources/2025-12-18-dropbox-feature-store-powering-real-time-ai-dash — DynamoDB as the API surface Dropbox's internal Dynovault is compatible with; Feast's DynamoDB adapter works against Dynovault unmodified. Confirms DynamoDB's value as a compatibility target even when the actual store is on-prem.
- sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization
— DynamoDB fills three distinct control-plane roles in Convera's
Verified Permissions architecture: (1) user/tenant attribute
store read by the pre-token
hook to enrich Cognito access tokens; (2) user-to-tenant
mapping table used by the pre-token hook to look up
tenant_idfor the JWT claim; (3)tenant_id → policy-store-idmapping used by the Lambda authorizer to route each request to the right per-tenant AVP store. Plus a fourth role — Cedar policy source of truth — with DynamoDB Streams capturing changes and a sync pipeline continuously propagating them into AVP policy stores. - sources/2026-02-25-aws-6000-accounts-three-people-one-platform — named alongside Lambda as the canonical scale-to-zero serverless primitive that makes account-per-tenant economically viable at ProGlove's scale (~6,000 tenant accounts, ~1M Lambda functions). On-demand DynamoDB bills per request and has no per-account provisioned floor, so replicating "one table per service per tenant" across thousands of accounts doesn't multiply idle cost the way a per-account RDS instance would.
- sources/2026-03-31-aws-streamlining-access-to-dr-capabilities — DynamoDB named as the canonical example of cross-Region backup coverage that AWS Backup added on top of a service that previously lacked it: "AWS Backup ... even enabled cross-Region backup for services like Amazon DynamoDB, which previously didn't have that capability."
- sources/2026-04-21-figma-the-infrastructure-behind-ai-search-in-figma
— DynamoDB as the metadata + embedding KV store for Figma AI
Search's indexing pipeline. Chosen explicitly over Figma's existing
RDS cluster because the workload "requires only a simple key-value
store, writing and reading at high throughput. No transactions or
foreign key relationships are required." Secondary role: the
authoritative source for
_source-slimmed OpenSearch fields — embeddings are removed from OpenSearch's_sourcefor size, then re-fetched from DynamoDB on every update to prevent updates wiping the embedding (patterns/source-field-slimming-with-external-refetch). - sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns
— DynamoDB is the high-frequency per-tenant backend in the
tagged-storage-routing split;
keyed
pk = TENANT#{id},sk = CONFIG#{type}for composite tenant-scoped query shape + built-in multi-tenant isolation at the data model level. Stores per-tenant feature flags, payment-gateway preferences, etc. accessed "thousands of times per minute". For sub-millisecond at 1000+ RPS the post names DAX as the acceleration layer (5-10× over DynamoDB's single-digit-ms baseline). Multi- dimensional tenant context (e.g.,pk = TENANT#{id}|SERVICE#{name}) named as the extension for service-level access-control beyond tenant-level.