Overview
Build the data layer for a campus event registration system. Your project must support listing attendees for one event and finding one student's registration within that event. The deliverable is a tested data model, not a complete public web application.
Architecture
The console is your test client; IAM authorizes it to access a dedicated DynamoDB table. The composite key groups registrations by event. Document how an authenticated API could be added later without giving a browser AWS credentials.
| Access pattern | Key operation |
|---|---|
| Attendees for an event | Query eventId |
| One attendee's registration | Query eventId plus studentId |
| Events for one student | Additional index or different model required |
Prerequisites
- Complete Model event registrations in DynamoDB.
- A learning AWS account and at least two hours for implementation and documentation.
- Synthetic records only; no real student details.
Steps
1. Build the first version
Follow the prerequisite lab to create a table, add three records, query one event, and update a status. Save the observed results. The lab includes creation and cleanup instructions; recreate the dedicated table if you already cleaned it up.
2. Expand the dataset
Expand the existing dataset to three event IDs with five student registrations each using the item editor: add three registrations to cloud-day, four to career-day, and five to a new event. You should have 15 items in total, including the three baseline items. Keep each eventId/studentId pair unique. Add a status attribute with either registered or attended. Write down the expected count per event before querying.
3. Test the access patterns
Query each event and compare the returned records with your expected counts. Query a single registration with both keys. Change one status, read it again, and confirm the update. Use consistent reads where available or account for eventual consistency.
4. Examine duplicate behavior
In the console, edit an existing item's non-key status attribute and save it. Observe that a table's complete primary key identifies one item. Explain why a public registration API would also need conditional writes and validation to handle duplicate requests safely; do not claim the console exercise implements that API.
5. Present a design extension
Design, but do not provision, a global secondary index for listing events by student. Specify its partition key, sort key, and projected attributes. Explain that additional index storage and writes have a cost, and that a GSI does not support strongly consistent reads.
Verification
Prepare a table of your three event IDs, expected counts, observed counts, and one status-update result. Include a diagram and answers to: Why these keys? When would a relational database fit better? How would you stop a user reading another user's registration?
Your project is complete when another learner can reproduce your small dataset and your documented queries return the stated results.
Cost and cleanup
Use on-demand capacity with a small synthetic dataset. Requests and storage may be billed; no always-free promise applies. Delete the dedicated table and any backups you explicitly created. Verify absence in the correct region. Keep evidence and your design document rather than leaving the table running for a viva.