Inspiration In times of disaster and crisis, our greatest enemy is the time constraint and the information blackout. While meteorological changes, seismic patterns, and visible signs from various sources (Kandilli, NASA FIRMS, Meteo) constantly flow in, the human factor struggles to analyze this massive amount of data in real-time and record the necessary actions. Crisis management is a manual process; the conditions for transforming it into an autonomous, asynchronous, and AI-powered decision-making support system were created by CrisisBrain. Our goal was to build a reactive system that not only monitors data but also understands and directs it.
What it does CrisisBrain is a backend architecture that collects, processes, and generates AI-based action plans in real-time from a large volume of sensor and warning data from various external sources. The system runs the following steps in the background: It asynchronously retrieves data from different APIs (seismic, meteorological, fire, etc.). It detects and categorizes anomalies in the incoming data (e.g., when the severity threshold S > t). It records each detected anomaly in the database and simultaneously sends it to the Gemini AI model. The AI generates clear and actionable steps (actions) in JSON format for field teams based on the urgency of the situation. All of this process takes place within milliseconds, without human intervention.
How we built it We built the heart of the project on speed, concurrency, and stability. We chose Go (Golang) for the backend architecture because its goroutine structure allows us to run multiple worker pools (Kandilli worker, NASA worker, etc.) in parallel without blocking the system. We asymptotically optimized our total data processing time thanks to the asynchronous structure. We used PostgreSQL for data persistence and structured storage. We indexed the AI-generated decisions and complex sensor data in JSONB format to enable high-performance queries. For AI integration, we used the Google Generative AI SDK, positioning Gemini models (gemini-1.5-flash/pro) as our decision support engine (Decision Service). On the interface side, we developed a React-based, dark-mode dashboard prototype with color coding based on the severity of the situation for crisis operators.
Challenges we ran into We encountered significant technical barriers while building a data pipeline of this size: Dependency Hell: On the Go side, we experienced compilation errors due to conflicts between Protobuf and gRPC dependencies during updates of external packages. We solved this problem by completely clearing the module caches (go clean -modcache) and fixing the dependency tree to stable versions. Asynchronous Data Integrity: Anomaly data needed to be written to PostgreSQL and simultaneously sent to the AI service. We overcame race conditions during the instantaneous transfer of the unique ID (Primary Key) returned from the database to the goroutine by adding the RETURNING id structure to our SQL queries and reading it safely into the struct (QueryRow().Scan()). AI API Limitations: We resolved 404 errors caused by Google API model naming (gemini-flash vs gemini-1.0-pro) and region/permission restrictions by directly analyzing the supported model list (ListModels) and switching to the most stable root (fallback) model.
Accomplishments that we're proud of Our greatest achievement is establishing a non-blocking background service that doesn't crash or block. Thousands of rows of data from different sources are processed without ever overloading the main thread. Furthermore, we've managed to transform AI from a mere "chatbot" into an industrial engine that generates structured (JSON) emergency reports that directly match database IDs, are parsable, and can be displayed directly on the interface.
What we learned This project showed us the importance of "system engineering" rather than just language syntax. We learned that real problems in the industry require more than just writing code; they involve system design, dependency management, dealing with API limits, and the ability to correctly interpret error logs (log parsing). We experienced firsthand how critical type safety (strict typing) and asynchronous programming (goroutines) are in Go when working with large-scale data.
What's next for CrisisBrain Real-Time Delivery: We will push new anomalies and AI decisions that appear in the database directly to the frontend dashboard (Leaflet.js map) via Server-Sent Events (SSE) or WebSockets without needing to refresh the page. DevSecOps and Cloud: We will Dockerize the application and move it to Kubernetes (K8s) clusters on AWS or Google Cloud, creating an auto-scaling structure. On the security side, we will integrate DevSecOps standards by adding automated vulnerability scans to the CI/CD pipelines.
Log in or sign up for Devpost to join the conversation.