CivicConnect hero background
← Back to indexProduction · Shipped

CivicConnect

Civic complaint and municipal-updates platform with an AI triage chatbot, running as a decoupled event-driven mesh.

Role

Systems design & implementation across the service mesh

Timeline

Shipped, 2025

Stack

  • Go·
  • Node.js·
  • Python·
  • Flutter·
  • Vue.js·
  • Docker·
  • Kubernetes·
  • RabbitMQ
OverviewArchitectureGallery

The problem

Civic complaint systems typically fail in one of two ways: they're a form that goes into a black hole, or they're a monolith where one overloaded module (usually the notification or classification piece) takes the whole system down during a spike. Municipal complaint volume spikes hard around specific events — a burst water main, a storm — exactly when reliability matters most.

Why event-mesh

Four services — intake, triage, routing, and citizen-facing status — talk only through a RabbitMQ event bus, never directly to each other. That decoupling means the triage service choking on a spike degrades the system gracefully: intake still accepts complaints, they queue, and they get processed as capacity allows, instead of the whole platform going down because one component fell over.

Where AI fits

A Gemini-backed chatbot handles first-pass triage — helping citizens articulate the actual issue and routing it to the right municipal queue before a human ever sees it. It's a feature inside the pipeline, not the product itself; the event-mesh architecture is what makes the system reliable, the chatbot just makes intake faster.

What's still open

Very high-volume bursts still cause temporary queue backlogs — the mesh degrades gracefully but doesn't yet scale itself automatically. Auto-scaling for the queue consumers is in progress to close that gap.