Architecture Patterns To Enable Stateful Communication Over Stateless Serverless Apis
summary
Claim: stateless serverless functions can host long-lived, ordered streams by layering a lightweight session layer and session ID mapped to an in-memory store that holds logs and ordering metadata. Uses HTTP/gRPC/WebSocket transports, Firestore-style watch APIs and push services (Firebase Cloud Messaging) as comparisons; proposes primitives: session creation, durable session store, and a push function that notifies clients. Case study sketches a real-time chat prototype with sub-second latency goals; solution exists as internal infrastructure work, not yet a public, finished product.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:57Overview
- 4:03Incremental Delivery
- 5:34Case Studies
- 6:56Challenges
- 8:18Latency
- 9:40Higher level abstraction
- 10:04WebSocket API
- 10:50State of Art
- 11:56Killer and Hood
- 13:00Can we have both
- 13:25Case study
- 14:31Realtime chat
- 15:19Session primitive
- 16:41Message primitive
- 17:10How to generate a message
- 22:06Stateful Communication
related talks
40mCloud architecture patterns, how to implement them in a serverless way
28m8 Keys for Successful Serverless Architectures
27mStateful Functions 3.0: Towards a Cross-Platform Stateful Serverless Stack
25mCloudstate—Towards Stateful Serverless
35mServerless is Interesting But FaaS is Not Enough
33mCloudstate Towards Stateful Serverless
43mRealtime Serverless Communication with
44mJava: From Stateless-Serverful to Stateful-Serverless
