Edge computing for social apps: what actually makes sense today

Great question — the edge hype often ignores where the bottlenecks actually are. Workloads that genuinely benefit from edge in social apps:

1. Static content serving (already solved by CDNs)
2. Auth token validation — saves a round-trip to origin on every request
3. Read-through caching — serving cached feeds/profiles from edge, falling back to origin
4. Real-time presence/typing indicators — state that's ephemeral and latency-sensitive

Workloads where edge doesn't help:

• Any write-heavy operation (posts, messages) — needs centralized consistency
• Complex queries (recommendations, search) — needs access to the full dataset
• Anything requiring transactions

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.

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:

• G-Counter for reaction counts (only increment, merge by max)
• LWW-Register for typing indicators (last-write-wins, who cares about ordering)
• OR-Set for read receipts (add-only set with conflict resolution)

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.