Namasvi — an Instagram-style events platform on a polyglot GCP backend

The problem

The client is building a social platform where users and sponsors create and participate in events — competitions, award shows, photo challenges — and share them the way they already do on Instagram. That meant three hard things at once: a real-time social feed, a genuine Instagram integration (publish and respond to comments/DMs), and two distinct apps (users and sponsors) on one backend.

I owned the backend and the cloud infrastructure.

Architecture

Rather than one monolith, the platform is a set of focused microservices on GCP Cloud Run — written in the language that fits each job:

• Go for the core API, the Instagram post/reel scheduler, and video composition (CPU-heavy work that benefits from Go's concurrency).
• Node.js for the auth service (WhatsApp OTP + Instagram/Facebook OAuth) and the Instagram comment/DM auto-reply.
• Firebase Realtime Database for the live event/participation feed, with a named Firestore for the Instagram automation workflows.

Each service has staging and production instances with strict environment binding, deployed through Docker-based scripts with cache-busting and Playwright smoke tests before release.

The build

Instagram, done properly. Publishing to Instagram is the easy direction; responding is the hard one. Incoming comments and DMs arrive as webhooks, which I push onto Cloud Pub/Sub and process asynchronously in a separate worker — so a spike in activity can never block or drop a reply, and the auto-reply logic scales independently of the ingestion endpoint.

One login, many surfaces. Auth runs on WhatsApp OTP (with an SMS fallback) and mints sessions the Flutter and React clients share, so a user, a sponsor and the admin panel all authenticate against the same service.

Engagement mechanics. A coin-based rewards and referral system turns likes, comments and shares into in-app value — modelled in the realtime database so the feed and the scores stay in sync.

Multi-platform delivery

The user app is a single Flutter codebase shipping to iOS, Android and Web; the sponsor app is a separate Flutter Web build; a small volunteer QR-scanner app rounds it out. iOS releases are automated through Codemagic with App Store Connect build-number syncing, so shipping a new build isn't a manual ritual.

Outcome

The result is a platform where the social feed, the sponsor tooling and the Instagram integration all run as independent, independently-scalable services on GCP — a backend that can grow one piece at a time instead of all at once. The polyglot-microservices approach let each part use the right tool without forcing the whole system into one runtime.

Reflection

Pushing the Instagram webhooks through Pub/Sub was the decision that made the integration robust — it turned a fragile, synchronous "reply before the request times out" problem into a calm, async pipeline. If I were starting again I'd invest in shared tracing across the services even earlier; with this many moving parts, seeing a request hop between Go and Node is worth a lot.