<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Playfair+Display:ital,wght@0,400..900;1,400..900&family=Libre+Caslon+Text:ital,wght@0,400;0,700;1,400&family=Libre+Franklin:wght@400..800&family=JetBrains+Mono:wght@400;500;700&display=swap" />
Late edition Stop the presses

Suspect at large

A backend developer is fleeing the scene. The record is being set.

Setting the type Inking the plates Running the presses

Skip to the front page
Kathmandu, NepalThe Backend EditionEst. 2021

The personal record of a backend developer

Wednesday 5 August 2026Vol. ISelected works & notesPrice: one coffee
← Back to the evidenceCase file · Exhibit B

Event-Driven Microservices

Interacta

Live Audience Engagement Platform

An event-driven microservice platform where a host runs a live session and the audience joins by QR code — asking questions, upvoting and voting in polls without ever creating an account.

Filed under
Event-Driven Microservices
Role
Backend developer, team of four
Status
In Development
Stack
11 technologies

The brief

Interacta is a live audience-engagement platform split into seven Spring Boot services and a Python worker, talking over Kafka rather than HTTP. A host creates a session, puts a join code on screen, and the room participates in real time — questions, upvotes, live polls and shared handouts — while STOMP over WebSocket fans every change out to the connected clients.

The defining constraint is that listeners never create an account. Joining a session mints a signed, PII-free participant token, so an anonymous listener is still a first-class API caller and one upvote per person is still enforceable. Every service validates two token issuers — Keycloak for staff, session-service for participants — and asks the same question of both: is this caller the host of this session, or a participant scoped to it?

The API, not the UI, is the security boundary: a hidden poll tally is zeroed in the DTO rather than merely unrendered, realtime frames are deliberately thin so the server decides what each viewer may see, and every service verifies its own tokens instead of trusting one check at the gateway. A Python AI worker screens questions for toxicity and clusters near-duplicates before they ever reach the room.

The findings

  1. 01

    Anonymous participant tokens — join by QR code, no account, no PII

  2. 02

    Two-issuer authentication with per-session authorization in every service

  3. 03

    Kafka event topology with a local session read-model per service

  4. 04

    Realtime fan-out over STOMP/WebSocket with per-destination authorization

  5. 05

    Live polls with server-side result withholding and recounted tallies

  6. 06

    AI moderation: MuRIL toxicity screening and BGE-M3 semantic grouping

  7. 07

    S3-compatible file storage with policy fixed on the upload category

  8. 08

    Per-caller rate limiting, RFC 9457 error shape, one-database-per-service

Backend developer specializing in Java and Spring Boot. Building scalable, reliable systems that power modern applications. This broadsheet is hand-set in Caslon and Franklin.

The desk

Tech stack

  • Java & Spring Boot
  • MySQL & PostgreSQL
  • Docker & Microservices
  • JWT & OAuth2
Case closed

System up since 2021 · Building backend systems · Learning new technologies · Contributing to open source

© 2026 Utsab Dahal · All rights reserved · Printed in Kathmandu