Why should you care?

Instagram-style app still needs consistent likes count and follow graph — MySQL with good indexes beats document store for “who follows whom” JOINs.

See it live — copy this example

Run in MySQL Workbench or the mysql CLI.

CREATE TABLE posts (
  post_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  author_id INT UNSIGNED NOT NULL,
  body TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE follows (
  follower_id INT UNSIGNED NOT NULL,
  followee_id INT UNSIGNED NOT NULL,
  PRIMARY KEY (follower_id, followee_id)
);
SELECT p.post_id, p.body
FROM posts p
JOIN follows f ON f.followee_id = p.author_id
WHERE f.follower_id = 7
ORDER BY p.created_at DESC
LIMIT 20;

What happened?

• Feed query: posts from people user 7 follows.
• Composite PK on follows prevents duplicate follows.
• Index (followee_id, created_at) on posts optimizes feed in production.

Practice next

1. Create posts and follows in DataFlow.
2. Insert users, follows, posts.
3. Run feed query for follower_id 7.
4. Add likes table and COUNT subquery on post.
5. Pagination with keyset (post_id < ?) not deep OFFSET.

Remember

Follow graph = junction with composite PK. Feed = JOIN follows to posts + ORDER BY time. Index for follower-centric queries.

DataFlow social module

Campus app prototype uses this feed query with Redis cache top 100 posts.

Outcome: MySQL source of truth; cache refreshes on TTL.