Forem: Sree Praveen Challa

EcoScanAI 🌍♻️: Scaling Sustainability with AI Vision

Sree Praveen Challa — Mon, 20 Apr 2026 06:48:48 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

EcoScanAI is an intelligent waste-management companion that turns a single photo into an actionable "Impact Report." By identifying materials and providing instant disposal guidance (Recycle, Compost, Landfill), it helps users build better daily habits to reduce their carbon footprint.

The goal was to bridge the "Analysis Gap" in sustainability—where people want to recycle but are confused by complex packaging—by providing structured intelligence in under a second.

Demo

Live App Link
App UI: Main scanning interface.

Health Check: https://ecoscan-ai-sha-c2ba78b.onrender.com/health

Code

I have open-sourced the entire engine here. Check out the architecture and the Gemini integration:

praveenarjun / EcoScanAI

This is a submission for Weekend Challenge: Earth Day Edition

EcoScanAI

EcoScanAI is an AI-powered image scanning app that analyzes an uploaded image and returns a structured JSON response (e.g., classification/insights) using a Vision-capable AI provider.
It includes rate limiting, security headers, hash-based caching, and strict JSON validation to keep results consistent and production-friendly.

Built for a competition / hackathon project — add your competition name and details in the section below.

Highlights

Upload an image and get back normalized JSON results
Go (Gin) API with a clean request flow
SHA-256 image hashing for cache keys
In-memory TTL cache to reduce cost and latency
Provider selector (Gemini Vision + optional Azure OpenAI Vision)
Strict schema validation for reliable output
Basic production middleware: rate limiter + security headers

Tech Stack

Backend: Go + Gin
AI Providers: Gemini Vision (primary), Azure OpenAI Vision (optional)
Caching: In-memory TTL cache (keyed by image hash)
Security: Security headers middleware
Reliability: Strict JSON…

View on GitHub

How I Built It

I approached EcoScanAI using the same "High-Performance" principles I use for my backend microservices

2. The "Smart Post Office" Architecture
To keep the system reliable and cost-effective, I implemented three key features:

Resilient AI Fallback (Azure AI Factory): The system is "AI-agnostic." While it defaults to Google Gemini 2.0 Flash for speed, I integrated Azure OpenAI as a heavy-duty fallback. If Gemini is unavailable, the system automatically routes the request to the GPT-4o model via Azure, ensuring the "Professor" is always available to analyze complex waste materials without downtime.

Deduplication & Caching: I used an in-memory cache with TTL to store results by image hash. If ten people scan the same plastic bottle, the AI only works once, saving 90% on API costs.

Rate Limiting & Security: To protect against "alert storms" or spam, I integrated custom middleware for rate-limiting and security headers.

Modern DevOpsI maintained a professional ship-speed by implementing GitHub Actions for CI/CD. Every push triggers automated formatting checks (gofmt), unit tests, and builds a Docker image published to GHCR for seamless deployment

Prize Categories

Best Use of Google Gemini: Utilized Gemini 2.0 Flash as the primary vision engine to extract structured JSON (material, disposal, carbon_save) from raw images.

Best Use of Azure AI Factory (GPT-4o): Leveraged Azure OpenAI Service to deploy GPT-4o, providing a high-intelligence fallback layer that maintains 99.9% availability for the EcoScanAI engine.

Best Use of GitHub Copilot: Used Copilot to accelerate the development of the Go-Gin boilerplate and the vanilla JS "Impact Score" rendering.

Let’s Build a Greener Future!
EcoScanAI is more than just a scanner; it’s a tool to turn a "graveyard of waste" into a live conversation about our planet. If you're interested in contributing to the AI prompts or expanding the "Impact Stories," check out the repo!

Author: Sree Praveen Challa
Teammates: (Solo submission)

The Smart Post Office: How I Defeated 3 Monsters to Build a Real-Time AI Log Analyzer

Sree Praveen Challa — Sun, 19 Apr 2026 19:05:09 +0000

The Post Office that Never Sleeps

Imagine a Post Office that receives 10,000 letters every single second. Most are just saying "Hello," but a few are screaming "Help! The building is on fire!". As an engineer, my job was to build a team of robots to find those "Help" letters before the fire spread. I built the Forensic Intelligence Engine to be that team.

But building it wasn't easy. I had to defeat three "monsters" that tried to shut my Post Office down.

Monster 1: The "Secret Password" Problem (SSL & Security)

The Struggle: One morning, my robots stopped talking to each other. It was like they all forgot the "secret handshake" to enter the building. Every time a robot tried to deliver a letter, the door slammed in its face—a classic SSL Handshake Failure.

The Solution: I realized the "ID Cards" the robots were using were stale. I built a Master Key System (a Centralized ConfigMap) that gave every robot a fresh, matching ID card at the exact same time. Now, the doors stay open, and the letters keep moving safely.

Monster 2: The "Expensive Professor" (AI Cost Management)

The Struggle: To understand the complicated "Help" letters, I had to send them to a Super Professor (the AI). But the Professor is very expensive; if I sent him all 10,000 letters, I would be bankrupt in minutes.

The Solution: I hired a "Speedy Gatekeeper" written in Go.

This Gatekeeper is a world class sprinter super fast but only looks for the scary words.

He throws away the "Hello" letters and only sends the high-signal "Help" letters to the Professor.

The Result: I saved 80% on my bills, ensuring the Professor only works on what truly matters.

Monster 3: The "Memory Storm" (Redis Deduplication)

The Struggle: When a computer breaks, it doesn't just send one "Help" letter; it sends thousands of the same letter every second. This is an "Alert Storm"—it's like 100 people calling you at once to tell you the same thing. It makes the Professor confused and overwhelmed.

The Solution: I gave the Gatekeeper a Magic Notebook called Redis.Now, when a "Help" letter arrives, the Gatekeeper writes it down.If 500 identical letters arrive a second later, he looks at his notebook and says, "I already know about this! I won't bother the Professor again".He only alerts the Professor once every 5 minutes for the same problem

The Conclusion: From Chaos to Clarity

Because I defeated these three monsters, my system doesn't just say "Something is broken". It tells me exactly why it broke and how to fix it. I turned a "graveyard of data" into a live, intelligent conversation.

What’s Next? Join the Mission!

I am still building, and the Post Office is getting bigger every day. If you love Distributed Systems, GenAI, or just building cool things that don't break, I'd love for you to join me.

Want to contribute? Check out the "Workers" under the hood and help me build the next generation of observability!

GitHub Repository: https://github.com/praveenarjun/Real-Time-AI-Log-Analysis-Platform

Let's Connect: https://www.linkedin.com/in/praveen-challa-6043a3276/

Are you ready to build the next "Smart Camera" for the world's data? Let's talk!

How I saved 80% on OpenAI bills while processing 10k logs/sec: My Journey Building a Cloud-Native AI Log Streaming Platform.

Sree Praveen Challa — Thu, 16 Apr 2026 16:41:36 +0000

When a system fails at 3 AM, the bottleneck isn't data it's human cognition. We have the logs, but we don't have the time to read 10,000 lines of JSON. I built the Forensic Intelligence Engine to bridge that gap, turning high-velocity telemetry into structured, actionable intelligence in real-time.

I built the Forensic Intelligence Engine to bridge that gap, turning high-velocity telemetry into structured, actionable intelligence in real-time.

The Problem: Log Fatigue & The "Analysis Gap"
In modern distributed systems, we usually face two extremes:
The Firehose: Millions of data points that no human can parse in real-time.
The Black Box: Dashboards that show that something is broken, but never why.

Traditional monitoring tells you the "What." I wanted to build something that tells you the "Why" and the "How to fix it" before the incident even escalates.

The "Why" (Explained simply) Imagine you are a security guard for a massive library with millions of books. Suddenly, someone reports that a single page is missing from one book. The Old Way: You have to walk through every aisle, open every book, and check every page. By the time you find it, the thief is long gone. The Forensic Engine Way: You have a "Smart Camera" system that knows exactly which book was touched, who touched it, and why the page is missing—all in a few seconds.

I built this because logs shouldn't be a graveyard of data; they should be a live conversation.

The "Magic" Under the Hood To make this work, I had to solve a big puzzle: How do you make an AI "read" thousands of logs without it getting confused or costing a fortune?

I used a Three-Step Pipeline:
The Fast Catch (Go): I used the Go programming language to catch logs. It’s like a world-class sprinter—super fast and handles thousands of logs at once without breaking a sweat.

The Conveyor Belt (Kafka): Instead of throwing logs directly at the AI, I put them on a "conveyor belt" called Kafka. This ensures that even if the AI is busy thinking, the logs are safe and waiting in line.

The Brain (AI Agents): This is the cool part. Instead of one big AI, I used LangGraph to create a team of "AI Agents." One agent looks for errors, another looks for the cause, and a third one double-checks the work.

Real Problems

I Hit (and how I fixed them)
It wasn't all smooth sailing. Here are two "walls" I hit while building this:

1.The "Bill Shock" Problem

Problem: Sending every log to a powerful AI (like GPT-4o) is very expensive. It’s like using a private jet to go to the grocery store.
Solution: I built a "Cheap Filter." A simple script looks for "high-signal" logs first. Only the important stuff gets sent to the expensive AI. This saved me tons of money and made the system much faster.

2.The "Too Much Information" Problem

Problem: Sometimes the AI would get "distracted" by useless logs and give a wrong answer.
Solution: I gave the AI "Context Windows." Instead of showing it everything, I only showed it the logs that happened right before and right after the error. It's like giving the AI a magnifying glass instead of a whole book.

The Result: From Chaos to Clarity
Now, when the "Log Simulator" starts throwing errors, I don't panic. I just look at the Command Deck.

Instead of seeing:
Error: 500 at /api/v1/login

I see:
AI Verdict: The Login is failing because the Database is out of memory. Try restarting the DB-Service.

That is the difference between data and intelligence.

Explore the Code

If you want to see how the "workers" are built or run the log simulator yourself, check out the repository:
GitHub:

Let's Connect

I’m always building and learning. Let’s talk about Distributed Systems or GenAI:

Portfolio: [https://praveenarjun.github.io/Portfolio-Website/]

LinkedIn: [https://www.linkedin.com/in/praveen-challa-6043a3276]

What’s Next?

Suspence