LetSlic — Social Media App with Group Chat, Stories and Premium

The problem

LetSlic's mobile API forks one Node.js worker per CPU core. Socket.IO keeps its rooms in each worker's memory, so a phone connected to one worker never hears an event emitted on another. Without shared state the symptoms were the familiar ones: connection counts that read zero, messages that reached the server and stopped there, and online status that disagreed between screens.

What we built

• A shared adapter. Socket.IO runs on the Redis adapter, so a room means the same thing on every worker.
• A personal room per person. On sign-in every socket joins user_<id>, across screens and devices. A message sent through the API is pushed to each recipient's personal room, not only to the chat's room, so it reaches someone on the chat list as well as someone with the thread open. Read receipts and per-recipient unread counts travel the same way.
• Status before presence arrives. Last-active time is stored, so a chat header shows a sensible status before the live presence event lands, and the chat list refetches when the app returns to the foreground.

Group moderation

Groups carry their own moderation: roles assigned per member, mutes and bans with an optional end date, pinned or scheduled announcements with reactions and comments, written rules and invite codes. Staff can open any chat in the superadmin console, see its participants and their roles, and archive or delete it.

Why not a cheaper gateway

A payment gateway such as Razorpay costs far less than Google's commission, but Google Play's Payments Policy requires Play Billing for digital subscriptions sold inside an app distributed on Play, and LetSlic was already published there. We wrote the reasoning up for the client, along with Google's User Choice Billing programme for India, which by our reading saves about 1.5% per transaction in practice. We recommended revisiting it once the subscriber base justifies the extra integration.

RevenueCat, with our own books

We first planned a direct Play Billing integration, then switched to RevenueCat: it handles receipt checks, renewals and billing retries, and covers Apple's store in the same SDK, so iOS becomes a dashboard change later. We kept the records on our side. Each RevenueCat webhook is stored first, with a unique index on its source and event ID, so a resent event is recognised and never processed twice; processing happens after the 200 goes back. Each money event becomes a ledger entry numbered LE-YYYY-NNNNNN. Plans are seeded by an idempotent script that dry-runs by default.

Ads that ask first

AdMob native ads, styled like posts, appear after every fifth post on Android. The consent form runs before the ads SDK starts. Anyone under 18, or with no date of birth on file, is tagged as under the age of consent and limited to G-rated ads. Whether Premium removes ads is one setting, PREMIUM_IS_AD_FREE, which governs the feed, the ads bootstrap and the ad-preferences row in Settings. In July 2026 the client chose to show ads to Premium members too, so it is off.

Video posting is switched off in the LetSlic app today: the create screens accept photos only and the reels tab is hidden. The client asked us to prepare for video anyway, so that turning it on later would not mean designing the media backend in a hurry.

The design

1. The app uploads the MP4 to the media bucket on S3.
2. The upload's S3 event starts a Lambda function, kept as a template in the repo, which submits an AWS Elemental MediaConvert job.
3. MediaConvert writes HLS to a second bucket: three renditions, 640×360 at up to 0.7 Mbps, 1280×720 at up to 1.5 Mbps and 1920×1080 at up to 3 Mbps, in H.264 with quality-defined variable bitrate, 96 kbps AAC audio and 6-second segments under one master playlist.
4. When the job finishes, EventBridge calls a webhook on the API that is protected by a shared secret.
5. The API stores the playlist's CloudFront URL on the post or story; a failed job leaves the video ready to retry.

Where it stands

The job settings, the Lambda template and the webhook are in the code, and we documented the AWS side step by step for the client: the MediaConvert role and queue, the Lambda trigger, the HLS bucket and its CloudFront route. That AWS side has not been set up, so the pipeline has never run end to end; wiring it up and testing it is part of switching video back on, together with an HLS player in the app. In the same pass we added a presigned direct-to-S3 upload endpoint to the API, for the app to adopt when video returns, and a CDN URL helper with a backfill script for existing media.