How We Fixed Real-Time Issues in Psychic Session PlatformHow We Fixed Real-Time Issues in Psychic Session Platform
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Taimoor's avatar
Taimoor Khan
pro
ā€¢ Jul 6
We built a real-time psychic session platform. Here's what broke first.
Kismaa is a live psychic consultation marketplace. Users pay by the minute for real-time chat and call sessions with psychics. Three user types (paying users, psychics, admins) all operating in sync, across iOS, Android, and web.
The use case sounds unusual. The engineering problems were universal.
What broke first: the 2-second gap.
A user taps "Connect." The psychic's web interface needs to ring instantly. Not in 2 seconds. Not after a loading spinner. Instantly. Because when someone is paying per minute for a live session, any perceived delay feels like the system is broken. And broken trust = refund request = churn.
Our first implementation used standard REST polling for session state. It worked in dev. In production, with real network conditions and real emotional stakes, a 2-3 second delay between "request sent" and "psychic notified" killed conversion rates.
The fix: Persistent socket connections with event-driven UI updates. No polling. The moment a user requests a session, the psychic's app reacts in milliseconds. We built a priority-based push notification pipeline as a fallback (push to in-app sync) with deep linking so psychics land exactly on the accept/reject screen.
What broke second: sessions dying mid-conversation.
A session lifecycle looks simple on paper: Request, Accept, Connect, Track time, Charge, End.
In reality, phones go to sleep. Users switch apps. Networks drop in elevators. The billing timer needs to keep running accurately regardless of what the device is doing.
The fix: Deterministic session state management with background-safe timers. Automatic state recovery after app interruptions. The server is the source of truth for billing; the client reconciles on reconnect. Sessions don't break even when mobile conditions do.
What broke third: the matching engine under concurrency.
Multiple users requesting sessions simultaneously. Multiple psychics going online/offline in real-time. The naive approach (check availability, assign, confirm) creates race conditions where two users get matched to the same psychic.
The fix: Queue-based, event-driven matching system. Atomic availability locks. The system handles concurrent requests without double-booking, and availability updates propagate across all connected clients in milliseconds.
The stack: React Native (mobile), Next.js (web + admin), Node.js + Prisma + PostgreSQL (backend), persistent sockets for real-time sync.
The takeaway for anyone building real-time multi-role platforms:
Your biggest risk isn't features. It's the gap between what users expect to happen instantly and what your system actually delivers instantly. Close that gap first. Everything else is polish.
ā†’ Full case studies: Kismaa Platform | Kismaa Mobile
Next.jsReact Nativerealtimeapp
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started