A deep dive into how Switchyy achieves real-time updates, low latency, and high reliability.
System Overview
Switchyyis built on a modern serverless architecture designed for speed, reliability, and scalability. Here's how the pieces fit together:
Edge Functions
API routes run on Vercel Edge for global low-latency responses.
Firestore + Redis
Firestore for persistence, Redis for caching and real-time events.
SSE Broadcasting
Server-Sent Events push updates to all connected clients instantly.
Rate Limiting
Redis-backed rate limiting protects against abuse (60 req/min/IP).
Request Flow
When your app makes a decision request, here's what happens:
- Request hits edge — Your request arrives at the nearest Vercel edge location.
- Cache check — We first check Redis for a cached decision (30-second TTL).
- Database fallback — On cache miss, we fetch from Firestore and cache the result.
- Response — The decision is returned with appropriate cache headers.
Average response time: <100msglobally, often <50ms with cache hits.
Real-Time Updates (SSE)
Our real-time update system uses Server-Sent Events for efficient one-way communication:
- Client connects — Your app opens an SSE connection to
/api/v1/events/[projectId]. - Mode change — When you update a mode in the dashboard, we write to both Firestore and Redis.
- Event broadcast — An in-memory event bus notifies all SSE connections for that project.
- Client receives — Your app receives the update and reacts immediately.
Why SSE over WebSockets?
- Simpler — Works over standard HTTP, easier to deploy and debug.
- Auto-reconnect — Built into the browser specification.
- Sufficient — We only need server → client updates.
- Compatible — Works with HTTP/2, proxies, and CDNs.
Caching Strategy
We use a multi-layer caching approach:
| Layer | TTL | Purpose |
|---|
| Redis (decision cache) | 30 seconds | Reduce Firestore reads for hot paths |
| Redis (event store) | 300 seconds | SSE replay for reconnecting clients |
| Redis (blocked cache) | 5 seconds | Brief cache for paused projects |
Rate Limiting
To protect the service and ensure fair usage, we implement rate limiting:
- Limit: 60 requests per minute per IP per project
- Implementation: Redis-backed sliding window
- Response: 429 Too Many Requests when exceeded
Security
- Public keys — Safe to expose in client-side code, scoped to specific projects.
- HTTPS only — All API endpoints require TLS.
- No sensitive data — Mode decisions contain only public information.