Everyone's talking about edge computing, but in the social product space I see a lot of hype and not much critical thinking. Moving your API to the edge doesn't magically make your app faster if 90% of your latency is database queries to a centralized PostgreSQL. What social app workloads actually benefit from edge?
Great question — the edge hype often ignores where the bottlenecks actually are. Workloads that genuinely benefit from edge in social apps:
Workloads where edge doesn't help:
The honest assessment: for most social apps under 10M users, a well-configured single-region setup with a good CDN gives you 90% of the benefit at 10% of the complexity.
What about CRDTs for edge-native social data? I've been exploring using CRDTs for things like read receipts, typing indicators, and reaction counts — data where eventual consistency is fine.
CRDTs for ephemeral social state is one of the genuinely good ideas in this space. The key properties align well: these data types tolerate temporary inconsistency, don't need global ordering, and benefit from low-latency local updates.
Specific CRDT types that map well to social features:
But be careful about scope creep. The moment you need 'Alice unsent her message and Bob needs to see that immediately,' you're back to needing strong consistency. CRDTs work for fire-and-forget state, not for state that has business-logic consequences.
My recommendation: use CRDTs for the specific use cases you mentioned, keep everything else on your centralized database, and resist the temptation to CRDT-ify more things than necessary.