Your task

1. Design. Decide what a notification has to store for the dropdown text to be built. Sketch it in the SQL workbench first if that helps. Think about: who receives it, who caused it, what kind it is, which post (if any), and how "unread" is represented.

2. Migration. Write 008_notifications.sql. Use constraints to make invalid notifications impossible, not just unlikely. Go through each sentence of the spec and ask whether the database can enforce it.

3. Data. Insert notifications for a few real events from the sample data, covering all three kinds.

4. Queries. Write the three the feature needs:

• the dropdown for one user
• the bell count for one user
• mark all as read for one user

5. Performance. Imagine this table with ten million rows. Run the dropdown query under EXPLAIN ANALYZE, decide which index it needs, add it to the migration, and check the plan uses it.

6. Try to break it. Insert a notification where the receiver and the actor are the same user. Insert one with a made-up kind like 'poke'. Insert a 'follow' that points at a post. Delete a post and check its notifications went with it.