System design · Event-driven architecture
Event-Driven Social Media Platform
How a social platform separates transactional writes from personalized feeds and full-text search.
The problem
Posts, relationships, feeds, and search have different storage and query needs. Keeping them in sync without tightly coupling every request is the central design challenge.
Features
- JWT authentication behind a Spring Cloud Gateway
- Transactional outbox for publishing content events
- Hybrid feed generation in Cassandra
- Independent Elasticsearch indexing with idempotent updates
My contribution
Built a text-only social platform with authentication, posts, threaded replies, follows, likes, personalized feeds, and search across independently owned services.
The approach
01
Commit the fact before publishing it
Social Service owns authoritative data in MySQL. A post and its outbox record are saved in one transaction; a background publisher sends the versioned event to Kafka. This avoids treating the database write and broker publish as one unreliable dual write.
02
Build separate views of the same event
Feed and Search services use different Kafka consumer groups. Each receives the content event and builds a query-specific projection in Cassandra or Elasticsearch. Stable content IDs allow duplicate deliveries to be handled idempotently.
03
Balance write cost against read cost
Ordinary authors use fan-out-on-write for feeds. Celebrity posts are merged when a timeline is read, avoiding a write to every follower for each popular author. Feed hydration uses OpenFeign to retrieve authoritative content.
The outcome
The design makes its consistency boundary explicit: a successful post is committed in MySQL, while feeds and search catch up asynchronously. At-least-once delivery can produce duplicates; idempotent consumers handle replay, and retained Kafka events can rebuild read models.
Next exploration