Design27 min
Pushing updates to clients the moment they happen.Authentication, authorization and protecting data from abuse.Capping how many requests a client can make per time window.Write the event to the database with the data, then publish it.Relational SQL database, the safe default for transactional data.Core featuresACID transactionsJoins, constraints, foreign keysStrong consistencyExtensions: JSONB, PostGIS, full-textRead replicas via streaming replicationWhen to useMoney, orders, anything needing transactionsRelational data queried with joinsThe default until scale forces otherwise
PremiumResearcher–Participant Chat
Two strangers, one of them anonymous, allowed to talk only while a study says so, at a scale where the hard part is policy rather than throughput.
What they’re really testing: Scale is easy. The hard part is authorization the chat service doesn't own: study lifecycle, a participant who must stay anonymous, and staff who must see everything without becoming the leak.
Premium
This design is on the Premium plan
Readers with Lifetime Access read it in full. Already bought it? Sign in from the top bar.
What’s inside
- Primary concepts and the hard part
- Requirements
- API / Model
- High-level architecture
- Trade-offs and deep dives
- Possible follow-up questions