Problem
Short-video feeds routinely OOM-kill on real phones, and a naive backend that proxies video bytes falls over under large uploads. The goal: a complete TikTok-style app (record, edit, and swipe an endless ranked feed) built solo end-to-end without those failure modes.
What I built / did
A full short-video social app: native video capture, an in-app editor, the upload/storage/transcoding backend, and a personalized feed.
- Vertical swipe feed with a session-ranked algorithm (scoring + seen-tracking, so clips never repeat).
- In-app camera: record with stickers, text overlays, and filters baked into the video.
- Sounds, trends, comments for the full social loop.
Architecture / technical decisions
Video pipeline: upload & storage
- Presigned direct uploads: the client requests a presigned URL from the NestJS API and uploads directly to MinIO (S3-compatible), so the API never proxies the video bytes and scales without choking on large uploads.
- ffmpeg transcoding normalizes every clip to a web-friendly 1080p H.264 stream server-side.
RAM management (why the app doesn't crash)
- Video feeds OOM-kill on real phones. I capped capture at 1080p, tuned the Android ART heap (largeHeap), pooled a single bounded-buffer player across the whole feed, and dispose every Skia frame texture during editing.
- Result: took a sticker/filter post from a 320 MB leak + process kill down to ~14 MB steady.
Crash observability
- Sentry wired to catch real-device OOMs and native segfaults, each one triaged and fixed, documented as engineering decisions (ADRs).
Result / impact
Took a sticker/filter post flow from a 320 MB leak and process kill down to ~14 MB steady, and shipped a stable production short-video app solo across product, mobile app, backend, and release.
Lessons learned
On mobile video, the whole game is memory. Bounded buffers, aggressive texture disposal, and never proxying bytes through the API are what kept the app alive on real phones.