DynamoDB Data Modeling: Blog Platform Example

Oleksandr Andrushchenko

3 min read

·

1 hour ago

--

Listen

Share

Press enter or click to view image in full size

This case study describes a production blog platform backed by Amazon DynamoDB. It covers familiar workloads such as latest posts, popular posts, author feeds, and tag-based discovery, alongside administrative features such as user moderation and contact messages.

The central design decision is how to turn those features into predictable database operations. The same post needs to appear in several views, each with its own selection and ordering rules. A single-table model and carefully chosen global secondary indexes make those access paths explicit.

Requirements

Functional requirements

The platform needs to support:

• Latest posts: display published articles in chronological order.
• Popular posts: rank content using a score derived from views, likes, or ratings.
• Article pages: retrieve individual posts through SEO-friendly slugs.
• Author feeds: list an author’s posts, filtered by publication status.
• Tag discovery: support tag-based browsing and autocomplete.
• User profiles: resolve users by email or username and connect identity-provider accounts to internal users.
• Administration: support user moderation and a chronological contact-message inbox.

Non-functional requirements

The design also needs to account for:

• Latency: target read responses below 100 ms for common requests, then validate that target with a representative workload.
• Traffic variability: handle changes in demand while monitoring hot keys, throttling, and request costs.
• Capacity management: use on-demand billing to reduce provisioned-capacity planning.
• Consistency: allow feeds and rankings to update asynchronously, while using base-table reads where current item state is required.
• Maintainability: keep key conventions and query requirements clear as the application evolves.

Start with Access Patterns

Before choosing keys, describe each read operation: what identifies the requested data, how it should be ordered, and how the client will paginate it.

For this blog, three seemingly similar features require different access paths:

• The homepage needs published posts ordered by time.
• The popular feed needs published posts ordered by score.
• An author page needs one author’s published posts ordered by time.

These requirements guide the partition keys, sort keys, and indexes.

In this example, chronological feeds use created_at_sk, a numeric timestamp. This gives creation order among published posts. If the product needs publication order, that requires a publication timestamp and a matching index design.

Single-Table Design Overview

Users, posts, tags, and other entities share one DynamoDB table. Each item has a composite primary key: a partition key named pk and a sort key named sk.

Prefixes such as USER# and POST# distinguish entity types.

For example, a post’s metadata can use:

• pk = POST#123
• sk = META

An impression record for that post can share the partition key and use a sort key such as IMP#USER#456.

This groups related records into an item collection. Slug mappings and tag memberships have their own keys and retrieval paths, while global secondary indexes support views such as latest posts, popular posts, and author feeds.

The next step is defining those keys and indexes precisely — and making sure the write operations keep the model consistent.

The full case study includes the entity tables, all ten index definitions, Python examples for creating and publishing posts, pagination, slug lookups, CloudFormation configuration, and operational trade-offs.

Read the full article here: DynamoDB Data Modeling: Blog Platform Example (case study).