Lesson 9Beginner1h 14mAssessment-backed

Data Modeling for Systems

Learn how product behavior, access patterns, entities, relationships, and state transitions shape production data models.

What you will be able to do

Model data from product flows instead of starting with tables.

Identify entities, relationships, ownership, and state transitions.

Separate write models, read models, and derived views.

Understand how data models affect APIs, storage choice, and system boundaries.

Use a practical data-modeling brief before choosing SQL or NoSQL.

Data modeling is deciding what facts the system must remember, who owns them, how they change, and how they will be read. Good models start from product behavior, not from database fashion.

Start With Product Flows

Before tables or collections, write the flows. A product flow reveals the entities, state changes, consistency needs, and read patterns the model must support.

Data modeling flow from product actions to entities relationships and read models — Product actions reveal entities, relationships, state changes, and read models.

Question	Why it matters	Example
What action happens?	Defines state change	User places an order.
What facts must be stored?	Defines entities and fields	Order, items, address, payment intent.
Who owns the data?	Defines service boundary	Order service owns order state.
How is it read?	Defines indexes/read models	Order history by user and status.
What must be correct?	Defines consistency need	Payment state and order state must not conflict.

Scenario: Course Progress System

SkillSkore needs to track course progress: enrolled courses, completed lessons, module scores, assessment attempts, and certificate eligibility. A naive model stores a single progress percentage. A better model stores the events and state needed to explain that percentage.

Entity	Important fields	Why
Enrollment	userId, courseId, enrolledAt, status	Connects a learner to a course.
LessonProgress	userId, lessonId, completedAt, timeSpent	Tracks learning progress.
AssessmentAttempt	userId, assessmentId, score, passed, submittedAt	Supports strict scoring and retry logic.
ModuleScore	userId, moduleId, score, unlockedAt	Supports beginner/intermediate/advanced motivation.
Certificate	userId, courseId, issuedAt, finalScore	Durable proof of completion.

Write Model vs Read Model

The write model protects correctness. The read model makes screens fast. They can be the same for simple systems, but high-read products often add derived views, indexes, caches, or search documents.

Model	Optimized for	Example
Write model	Correct changes	Store assessment attempt with immutable submitted answers.
Read model	Fast display	Show dashboard with course progress, next lesson, and current score.
Derived view	Precomputed summary	Module completion percentage by user.
Search model	Text and ranking	Search lessons by title, concept, and keyword.
Analytics model	Long-term analysis	Daily active learners and pass rates.

Design principle

Model the truth first, then add read optimizations. If you only model the current UI, the system breaks when product requirements evolve.

Cloud Storage Mapping

Need	AWS	GCP	Azure
Relational truth	RDS/Aurora	Cloud SQL/Spanner	Azure SQL
Document/key-value access	DynamoDB	Firestore/Bigtable	Cosmos DB
Object/files	S3	Cloud Storage	Blob Storage
Search model	OpenSearch	Vertex AI Search/Elastic on GCP	Azure AI Search
Analytics store	Redshift/Athena	BigQuery	Synapse/Fabric

Modeling Brief

Section	What to write
Core entities	The main nouns the system must remember.
Ownership	Which service/module owns each entity.
State transitions	How each entity changes over time.
Read patterns	The screens, APIs, jobs, and reports that read data.
Correctness rules	What must be consistent and what may lag.
Retention	How long data must be stored and why.

Beginner Mistakes

Starting with SQL vs NoSQL before understanding access patterns.
Saving only the current UI state and losing important history.
Letting multiple services own the same data.
Ignoring read patterns until the application is slow.
Forgetting retention, audit, and deletion requirements.

Guided Practice

Practice task

Model a basic comments feature. List entities, important fields, owner, read patterns, and one correctness rule.

Sample Answer

Part	Example
Entities	Post, Comment, User, CommentReaction.
Owner	Comment service/module owns comments and reactions.
Read patterns	List comments by post, count comments by post, list recent comments by user.
Correctness rule	A deleted comment should not appear in normal reads, but may remain in audit history.
Optimization	Maintain comment count as derived data if reads are heavy.

Before You Continue

You should be able to model data from flows.
You should understand entities, ownership, read patterns, and state transitions.
You should know the difference between write models and read models.
You are ready to choose SQL or NoSQL based on the model instead of hype.

Sync vs Async Communication

SQL vs NoSQL Thinking