Loopedin Platform

What is LoopedIn?

LoopedIn describes itself as a real-time social app for nightlife, events and what is happening around you. Its feed mixes short videos, called Loops and Flicks, from people nearby and creators a user follows, with local events, parties and meetups. Users can host their own events, sell tickets, track RSVPs and manage attendees, connect with people they know through the Loop system, and find new people nearby with LoopFinder. A LoopScore reflects how active someone is, with levels and badges on top.

The product idea is to close a gap between two things that usually live in separate apps: a video feed that knows nothing about where you are tonight, and an events listing with none of the social proof a feed generates. When they are separate, a user who finds an event has to leave the feed to learn about it, and a video posted from an event has no structured link to the event itself.

That is a backend problem before it is a design one. One system has to carry media-heavy video uploads, discovery queries bounded by place and time, and live messaging between people who have just found each other, all against the same accounts.

What did Sameem build?

Sameem worked on LoopedIn as an engineer at Zencloud and built the backend. It is a TypeScript backend with a microservices-ready structure, a serverless video pipeline on AWS MediaConvert that turns uploads into adaptive HLS streams for mobile playback, a real-time messaging and notification layer on Socket.io and Redis, and the engine behind LoopScore.

The iOS and Android apps talk to that backend. Both store listings use the bundle identifier com.zencloud.loopedin, which is Zencloud's namespace.

LoopedIn launched in September 2026. The sections below explain how its backend is designed and why.

How is the LoopedIn backend structured?

The backend is written to be microservices-ready: video processing, real-time messaging and the core API sit behind separate boundaries so that each can be deployed and scaled on its own. The reason is that the three workloads use resources in almost opposite ways.

Video processing is bursty and compute-heavy, arriving in spikes with idle time in between. Real-time messaging is the reverse: light per message, but holding many long-lived connections and the memory that comes with them. Feed and discovery reads are frequent, cacheable and sensitive to latency.

Putting all three in one process forces every part to scale on the profile of the greediest one. Keeping them apart lets each scale on its own signal and contains failure, so a transcoding backlog cannot take messaging down with it. It also keeps deployments independent, so the parts that change fastest are not held back by the parts that must stay up.

How does the serverless video pipeline work?

Video goes through a serverless pipeline on AWS MediaConvert, deliberately kept off the request path. An upload does not wait for transcoding: it is accepted, handed to the pipeline as a MediaConvert job, and moves through job submission and completion events until the finished stream is ready for the feed.

The output is HLS, the adaptive streaming format that iOS and Android video players support. Each video is encoded into several renditions at different bitrates, and the player switches between them as the connection changes. For an app used on nights out, on crowded mobile networks, that is the difference between a clip that plays and one that stalls.

Transcoding is the most expensive and least predictable operation in a short-video app. Holding an HTTP connection open across it would tie user-facing latency to encoder speed and turn every burst of uploads into a wave of timeouts. A managed, job-based service also removes the encoder fleet: there is no cluster sized for peak uploads and left idle in between, only jobs to submit and completion events to react to.

The pipeline gives the feed an honest state model as well. A video moves from uploaded to processing to ready, and the feed should only ever show an asset that is actually playable.

How does real-time messaging work with Socket.io and Redis?

Messaging and notifications run on Socket.io backed by Redis. Socket.io owns the connection with each device: transport negotiation, fallback when WebSockets are blocked, heartbeats and reconnection, which on mobile networks is routine rather than exceptional.

Redis solves what Socket.io alone cannot. Once the messaging tier runs on more than one Node.js process, a socket connected to one process knows nothing about a socket connected to another, so a message emitted on the first never reaches the second. Redis acts as the shared pub/sub channel that carries messages between processes, which is what lets the messaging tier grow by adding processes instead of being capped by one.

The same Redis layer holds the short-lived state that real-time features depend on and a relational database handles badly: presence, room membership and notification fan-out, which are written constantly, read immediately and rarely need to outlive the session.

How does the LoopScore reputation engine work?

LoopScore is LoopedIn's reputation score. The store listing describes it as reflecting how active and engaged a user is, with levels and badges for hosts, attendees and creators. In an app where strangers meet around real-world events, a signal built from how someone actually behaves helps separate a credible host from noise.

Reputation is a derived value, not something a user submits. It is calculated from activity that already flows through the backend, which suits an event-driven design: services record what happened, and scoring consumes those events rather than being called in the middle of each interaction.

Kept that way, posting a video or sending a message never waits on a score recalculation, and the scoring rules can be retuned without touching the services that produce its inputs. Ranking reads, meanwhile, are the kind of hot, sorted, in-memory workload Redis is designed for.

What are the hardest engineering problems in an app like this?

The difficult parts of an app like LoopedIn are concurrency problems in different forms.

The first is real-time fan-out. Delivering messages across several connection processes means every process has to learn about events it did not originate, while phones on mobile networks drop and reconnect constantly and expect to come back to a consistent conversation, not a gap.

The second is media state. A video is not a row that appears once; it moves through stages, and the feed has to represent each stage honestly without presenting something that will not play.

The third is how they interact. Discovery is bounded by place and time, so results go stale quickly and cache invalidation never stops, while reputation, messaging and video all change what a given user should see next. Keeping those consistent is the reason the backend separates its workloads in the first place.

Where can you see LoopedIn?

LoopedIn is live on both stores. On the App Store it is listed as LoopedIn-Life (app id 6757230032), released on 29 September 2026. On Google Play it is listed as LoopedIn under the package name com.zencloud.loopedin, live since September 2026. The website is loopedin.life.

The video feed, messaging and LoopScore are the parts of the app that rest on the backend work described here, so the apps are the place to see it running.

Why this stack

• TypeScript — the main language, and a good fit for a microservices-ready backend. Once a system is split into separately deployed services, the contracts between them stop being checked by one codebase's compiler and become the main source of runtime failure. Shared types turn those boundaries back into something the build checks, so a changed event payload or a missing authentication field shows up at build time instead of in production.
• Node.js — the runtime for a workload that is mostly waiting rather than computing. Messaging fan-out, notification delivery, discovery reads and video job orchestration all wait on sockets, caches and remote services, which a non-blocking event loop handles efficiently: one process holds many concurrent connections without a thread per connection. It also keeps every service in one language, so types and validation logic are written once.
• AWS MediaConvert — a managed, job-based transcoding service instead of self-hosted encoders. Transcoding is the most expensive and least predictable work in the app, and the serverless model means no capacity is provisioned for peak uploads and left idle between bursts. It makes transcoding asynchronous by construction, so the upload path returns straight away, and its HLS output gives mobile players adaptive-bitrate playback.
• Socket.io — the real-time transport layer, chosen because raw WebSockets are only part of the problem. It handles transport negotiation and fallback where WebSockets are blocked, plus heartbeats and automatic reconnection, which on the mobile networks a local-discovery app runs on are the normal case rather than an edge case. That removes a large amount of connection-lifecycle code from the application itself.
• Redis — the component that lets the real-time tier run on more than one process. As a pub/sub backbone it carries messages between Node.js instances, so a device connected to one process receives messages that originate on another; without it, messaging is capped at a single process. Its in-memory data structures also suit the state real-time features generate (presence, room membership, notification fan-out and reputation ranking), which is written constantly, read immediately and rarely needs durable storage.
• Microservices-ready architecture — the organising decision the rest follows from. Bursty transcoding, connection-heavy messaging and latency-sensitive discovery have incompatible resource profiles, so separate boundaries let each scale on its own signal instead of on the greediest component's. It also isolates failure, keeping a transcoding backlog from degrading messaging, and decouples deployment so fast-moving parts are not gated on the ones that must stay available.