This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Find-Your-Route is an edge-aligned, high-throughput civic transit co-pilot and real-time ecological impact dashboard built with an extreme focus on backend architectural optimization, low-latency pipeline performance, and offline resilience.

By applying production-grade backend engineering principles, such as semantic Redis caching, upstream rate-limiting protection, and decoupled micro-pipelines, the system bridges the gap between raw physical tickets and immediate, intelligent transit routing. Commuters upload a photo of a physical paper ticket and receive custom-tailored travel itineraries alongside visual greenhouse gas offsets in under two seconds.

The Core Problem

Most AI-driven transit or navigation solutions suffer from three fundamental bottlenecks:

1. Unacceptable Latency: Running raw images through heavy multimodal vision models takes upwards of 80 seconds, which is completely non-viable for commuters moving through busy metro turnstiles. Uploading the same ticket at different times would call the API again, which increases latency and wastes computation.
2. Connectivity & Availability Drops: Cloud-only APIs fail completely inside deep underground transit corridors or under heavy API rate-congestions.
3. Redundant Computation: Re-running costly LLM queries for the same common commuter routes drives up latency and API expenses.

The Solution: An Optimized Backend Architecture

To solve this, we designed Find-Your-Route around a modular, decoupled backend built to deliver lightning-fast responses:

• One-Command Containerized Deployment: The entire backend ecosystem (FastAPI, EasyOCR pipelines, and the Redis cache) is fully Dockerized. A single command (docker compose up --build) spins up the entire stack on any machine, making deployment instant and reproducible.
• The Decoupled Ingest Pipeline: Rather than relying on cloud vision APIs, a local, high-speed EasyOCR pipeline extracts raw ticket text, which is parsed by regex-based station tokenizers in ~1.6 seconds.
• High-Performance Redis Caching: Commuters traveling the same routes hit a canonical source:destination key in memory. The system retrieves pre-computed route insights in under 1ms, yielding a blazing-fast warm-cache API response of ~1.8 seconds (completely bypassing LLM latency).
• Dual-Model Edge Fallback & API Protection: If cloud APIs face rate limits or latency spikes, the backend automatically fails over in less than 500ms to a local Ollama instance running Gemma 4 E2B on edge infrastructure, ensuring transit guidance is never disrupted.
• Low-Memory Profile Optimization: By utilizing customized Ollama runtime parameters, the local Gemma 4 E2B model runs smoothly on standard development laptops and low-memory profiles, making offline edge-deployment highly viable.
• Vibrant Eco-Analytics Dashboard: Frontend React Native elements consume rapid, clean JSON payloads to render interactive, SVG-based ecological footprint metrics (trees saved, carbon saved), upcoming metro timings and carriage crowding heatmaps.

Demo

gemma4-challenge.mp4 - Google Drive

drive.google.com

Code

AfreenInnovates / gemma4-e2b

Find-Your-Route

AI-Powered Multimodal Civic Transit Co-Pilot & Eco-Impact Dashboard

Find-Your-Route is a civic transit co-pilot for ticket OCR, route guidance, caching, and eco-impact comparison. It uses Google's Gemma 4 models, Redis-backed caching, and a responsive dashboard.

What it does

• Scan a physical ticket image.
• Extract and normalize station details with OCR preprocessing.
• Generate route guidance with Gemma 4.
• Compare carbon impact and travel cost against other transport options.
• Use local Ollama fallback when online API access is unavailable.

graph TD
    A[Physical Ticket Upload] -->|react-native-image-picker| B[OCR Extraction Pipeline]
    B -->|FastAPI Preprocessing| C[Station Extractor / Normalization]
    C -->|Check Redis Cache| D{Cache Hit?}
    D -->|Yes: sub-second| E[Render UI Response]
    D -->|No: Cache Miss| F[Gemma 4 31B Dense Primary]
    F -->|API Congestion/Failure| G[Gemma 4 e2b Local Fallback]
    F -->|Generate Route Markdown| H[Store in Redis Cache]
    G -->|Generate Route Markdown| H
    H --> E

Loading

Quick Start

• Prerequisites: Docker, Docker Compose, and either an…

View on GitHub

How I Used Gemma 4

The Architectures We Chose & Why

To power our real-time commuter co-pilot, we designed a Hybrid Intelligent Routing System leveraging two primary Gemma 4 architectures:

1. Primary Brain: Gemma 4 31B Dense (google/gemma-4-31b-it:free)
   • Role: High-throughput Cloud Reasoning Engine.
   • Why it fits: Crafting navigation itineraries requires highly accurate multi-step reasoning. Gemma 4 31B Dense excels at reading raw JSON databases of train lines, understanding platform interconnections, and formatting instructions in elegant, bite-sized markdown that is easy for commuters to read on the move.
2. Local Fallback: Gemma 4 E2B (gemma4:e2b)
   • Role: Resilient Edge Deployment via Ollama.
   • Why it fits: The E2B model is highly optimized for local/offline deployment on restricted hardware (like station ticketing computers or local server nodes). It offers extremely high reasoning efficiency with a small memory footprint, ensuring that even if public internet connectivity drops in underground terminals, the local fallback is triggered in less than 500ms to guide commuters safely.

The Orchestration Pipeline

Engineering Challenges & Breakthroughs

Challenge 1: The Local Memory Bottleneck (8GB RAM Limit)

• The Problem: During local testing, the system would regularly freeze and throw Out-Of-Memory (OOM) crashes. Ollama would struggle to run Gemma 4 concurrently with Docker, VS Code, and multiple open browser tabs.
• The Fix: We initially had to close all background apps and tabs just to keep Ollama alive. Recognizing that this was a bad user experience, we researched and implemented the Low-Memory Profile (gemma4-lowmem).

Challenge 2: Docker Container Networking & Redis Configuration

• The Problem: Orchestrating a FastAPI backend with a Redis cache using Docker Compose caused repeated connection failures, with the backend unable to reach the Redis container during startup.
• The Fix: We initially configured Redis using localhost / 127.0.0.1, but that did not work because each Docker container runs separately. We fixed it by changing the Redis host to redis (REDIS_HOST=redis), removed password setting, and updating the Docker setup so the backend could connect to Redis properly.

Images of the app!

Submitted by Afreen Hossain