Batalha dos Barris — TV Ranking Player

Problem

A brewery needed consumption rankings on a TV/monitor, fed by the venue POS. Hardware was an Android TV Box running 24/7; the network dropped; the POS rebooted daily. Without manual babysitting, data still needed to stay near real-time.

Solution & impact

A monorepo with an Angular 17 PWA player, a Flask/PostgreSQL API (cache + OpenAPI), and a Python agent syncing POS MySQL sales over an SSH tunnel, with state resume and periodic incremental sync. The engineering outcome is an end-to-end chain stable enough to run unattended on the floor.

Architecture & trade-offs

Splitting player, API, and agent isolated failures: the front tuned for constrained hardware does not depend on legacy MySQL; the agent owns SSH tunnel and POS lifecycle complexity. API caching reduces PostgreSQL pressure under player polling. Trade-off: periodic sync is not true streaming — it is pragmatic near-real-time, simpler to operate than websockets on a TV Box.

Operations & observability

Deploy via GitHub Actions; Cypress on the player. Agent healthchecks and sync lag alerts are the next level — today resilience comes from state resume and a network-tolerant periodic interval.

Technical challenges

Resilience to network drops and POS restarts, correct sync-cursor resume, and a fluid ranking UX on a TV Box with a Service Worker — plus automated deploy (GitHub Actions) and Cypress coverage on the player.

What I'd do differently

I would formalize agent healthchecks and lag alerts earlier. The periodic interval and resume model still fit; what I would strengthen is operational observability for a 24/7 environment.

Stack

• Angular 17
• TypeScript
• RxJS
• Angular Service Worker
• Flask
• PostgreSQL
• psycopg
• Python
• Docker
• GitHub Actions
• Cypress