This section explains all DynamoDB tables defined inside the backend architecture.
Each table serves a specific role in powering article management, user interactions, gallery rendering, location services, and user profiles.

Purpose:
Stores all articles created by users. Each record represents a complete travel post including metadata, visibility settings, timestamps, and ownership.
Primary Key:
articleId (HASH)Attributes:
visibility — public/privatecreatedAt — ISO timestampownerId — ID of the user who created the articlestatus — draft/published/flaggedIndexes:

Purpose:
Stores the relationship between a user and the articles they have favorited.
Primary Key (Composite):
userId (HASH)articleId (RANGE)This structure allows efficient:

Purpose:
Stores metadata for individual images extracted from articles.
Used for gallery browsing, filtering by tags, and building trending metrics.
Primary Key:
photo_id (HASH)Metadata may include:
articleId — which article the photo belongs to
Purpose:
Maintains tag popularity statistics for the gallery.
The article/image ingestion process updates counts within this table.
Primary Key:
tag_name (HASH)Usage:

Purpose:
Stores public profile information of users displayed in article feeds and profile pages.
Primary Key:
userId (HASH)Attributes include:
This table keeps profile data separate from Cognito, allowing customization and public display without exposing private identity data.

Purpose:
Caches results from AWS Location Service’s reverse-geocoding to reduce cost and improve performance.
Primary Key:
geohash (HASH)Attributes:
TTL — automatically deletes outdated entriesTogether, these DynamoDB tables form the storage foundation for:
They are optimized for serverless workloads with high scalability and low latency.