Module 03: Data And State

Understand what systems remember, how they remember it, and how bad state causes real incidents.

State is memory. Data is not just values. Data has owner, shape, meaning, lifetime, permissions, and consequences.

event happens -> validate -> store state -> read state -> make decision

A database is like a bank ledger. You do not scribble random notes in it. You define what a valid entry looks like, who can write it, when it can change, and how to audit history.

• Schema: allowed structure.
• Constraint: rule the database enforces.
• Index: speed helper for reads.
• Transaction: group of changes that succeed or fail together.
• Migration: controlled schema change.
• Backup: recovery copy.
• Restore: proof that backup works.

Browser state: form draft, loading, selected tab
API state: request context, auth user
Database state: tickets, comments, users, audit events
Cache state: recent dashboard counts
External state: payment or model job status

Design a support-ticket database:

• Users.
• Tickets.
• Comments.
• Attachments.
• Status history.
• Audit events.

Decide:

• What can be updated?
• What should be append-only?
• What must be unique?
• What must never be null?
• What should happen on delete?

• Ticket points to a deleted user.
• Comment exists without a ticket.
• Status has an invalid value.
• Migration deploys before code is compatible.
• Dashboard reads stale derived data.
• Backup exists but restore has never been tested.

Ask an agent:

Review this support-ticket schema for missing constraints, weak auditability,
bad delete behavior, privacy risks, and queries that may need indexes.

• What is the source of truth for ticket status?
• Should status history be editable?
• Which table stores files versus file metadata?
• What data is personally identifiable?
• What query must be fast for support agents?
• What is the rollback plan for a failed migration?

1. Create portfolio/03-data-and-state/schema.md.
2. Write tables and fields.
3. Add constraints.
4. Write five common queries.
5. Add index choices and explain why.
6. Write one migration.
7. Write a rollback plan.
8. Write a restore drill: how would you prove backups work?

• You can trace one ticket through its full lifecycle.
• You can explain what data is mutable versus append-only.
• You can identify sensitive data.
• You can explain migration risk.