CloudFYP

A real-time cloud networking layer that gives apps low-latency communication, smart routing, and region control without complex backend work

Comment

Inspiration

I built this system because I kept noticing the same problem everywhere: real-time apps fall apart the moment things get busy. Latency spikes, data sync breaks, messages get delayed, and everyone pretends it’s “normal.” It bothered me enough that I wanted to fix it. So I tried a different angle: what if real-time connectivity didn’t need traditional servers at all?

That’s where the idea for my Serverless Cloud Networking Architecture came from. Instead of relying on a single server to handle everything, I designed a setup where devices talk through a distributed edge network, backed by automated API key provisioning, identity control, and event-driven routing. The goal was simple: fast, reliable, and scalable communication with zero server babysitting.

I learned a lot while building this. Most of it was realizing how messy things get when you combine authentication, state, real-time messaging, and cross-device syncing all at once. Small things like API keys, client identity, and message queues ended up being the backbone of the entire system. I also had to rethink how latency is measured because users expect instant updates, not delayed logs that read like a postmortem.

How we built it

I started by sketching out the flow: A user connects and gets a secure Client ID plus an API key. Their device opens a WebSocket to the edge network. Every message travels through a serverless routing layer that scales horizontally. The admin dashboard manages users, resets keys, tracks latency, and monitors events in real time. From there, I built the backend using a combination of serverless functions, a low-latency edge runtime, and a distributed data layer. The frontend was built around a simple principle: everything updates instantly, and nothing should require a page refresh. That meant real-time hooks, reactive state, and bi-directional channels for audio, text, and file events.

Challenges we ran into

Everything that could cause pain… caused pain:

API keys sometimes failed to generate at first

Client IDs wouldn’t validate

Latency wouldn’t update properly

Real-time messages occasionally froze

Audio uploads got stuck

File selection broke when running inside the browser sandbox

Existing ports (like 3000) were already occupied

The admin panel needed a full reset-key workflow

But the biggest challenge was making all parts work together without turning the system into a spaghetti monster. Real-time systems are unforgiving; if anything lags or fails, the user notices instantly. I had to rebuild some components twice just to get clean reliability.

Every problem pushed me to refine the architecture, automate more tasks, simplify flows, and add proper error-handling. In the end, the system became something I’m genuinely proud of—clean, fast, stable, and actually scalable.

Built With

Share this project:

Updates