Chennai Flood Pulse: Building a Hyperlocal Flood Intelligence Platform on AWS
How I built and deployed Chennai Flood Pulse as a solo developer for Environmental Hacks, exploring AWS serverless architecture to support flood-related reporting, data processing, and environmental awareness.
Author: Ram Kumar
Hackathon: Environmental Hacks — WeMakeDevs × AWS, Bharat Builds Tour 02
Track: Heat and Water
Live Demo: Chennai Flood Pulse
1. Introduction:
When heavy rainfall affects Chennai, waterlogging and flooding can disrupt everyday life. Commuters may struggle to travel, residents may have difficulty understanding local conditions, and communities need reliable information to make informed decisions.
The challenge is not only about flooding itself. It is also about how environmental information can be collected, processed, and communicated in a useful way.
I wanted to explore how cloud technology could help address this problem. That idea led me to build Chennai Flood Pulse, an environmental technology prototype focused on flood-related awareness, reporting, and information processing.
I built this project independently as a solo developer for Environmental Hacks, part of the WeMakeDevs × AWS Bharat Builds Tour.
My goal was to go beyond building a simple interface. I wanted to explore how AWS services could support an application, from frontend hosting to backend processing, data storage, and monitoring.
2. Why Chennai Flood Pulse?
I chose the flood-intelligence problem because environmental challenges affect people's daily lives. Technology can help organize information, but that information must be relevant, timely, and presented responsibly.
I wanted to explore three important capabilities:
- Environmental awareness: Help users access relevant flood-related information.
- Community reporting: Explore how local observations and photographs can contribute to reporting workflows.
- Cloud-powered processing: Use AWS services to support backend requests, data storage, scheduled tasks, and potential notification workflows.
Rather than attempting to solve every aspect of flood management, I focused on building a prototype that demonstrates how these capabilities can fit into a cloud-based application.
The project also gave me an opportunity to learn by implementing a complete application instead of studying cloud services individually.
3. See Chennai Flood Pulse in Action
A project becomes easier to understand when people can see how its interface presents information.
Watch the project demonstration:
In the demo, I showcase the application and its user-facing workflows. The live application is also available here:
The purpose of the prototype is to explore how flood-related information, map-based visualizations, and cloud-backed application functionality can come together in one interface.
4. Exploring Preferred Routes, Risk, and Flood Hotspots
Flood-related travel decisions involve more than finding the shortest path. Users also need to understand potentially affected areas and the information available about conditions along a journey.
Preferred Route and Risk Visualization
Figure 1:
Preferred route and associated risk visualization in Chennai Flood Pulse.
This visualization demonstrates how route information and risk-related information can be presented together. The objective is to help users consider environmental conditions alongside their travel plans.
A displayed route should not be interpreted as guaranteed safe. Its usefulness depends on the quality, freshness, and accuracy of the underlying data and risk calculations.
Flood Hotspots
Figure 2:
Flood hotspot visualization for identifying areas that may require additional attention.
A hotspot view can help users understand where flood-related concerns have been identified. It can also provide a useful starting point for exploring how local reports and environmental information could be organized geographically.
These visualizations are intended to support awareness and exploration. They are not a substitute for official flood warnings, verified road closures, or emergency guidance.
5. Building the Project as a Solo Developer
I developed Chennai Flood Pulse on my own. I was responsible for the application, technical decisions, AWS integration, deployment, debugging, and documentation.
Working solo meant that I could not focus only on frontend development or backend coding. I had to understand how the different components worked together.
I organized the work into manageable stages:
- Understanding the problem and defining the project scope.
- Building the user-facing application.
- Planning the backend architecture.
- Integrating AWS services.
- Deploying the application.
- Investigating configuration and integration issues.
- Testing the available workflows and documenting the architecture.
The most valuable part of this experience was learning to take ownership of the entire system. A feature is not complete simply because its interface exists; its underlying workflow must also work as intended.
6. AWS Architecture: From Frontend to Cloud Services
I designed the application around a serverless architecture using AWS managed services.
The central request flow is:
Frontend → Amazon API Gateway → AWS Lambda → Amazon DynamoDB
The supporting services provide additional capabilities according to the features implemented and configured in the application.
Architecture Diagram
Figure 3:
High-level AWS architecture for Chennai Flood Pulse, illustrating the frontend, API layer, compute functions, data storage, scheduled processing, and supporting services.
AWS Services and Their Responsibilities
AWS Amplify — Frontend hosting
Amplify hosts the deployed frontend, making the application accessible through a public URL.
Amazon API Gateway — API entry point
API Gateway provides the HTTP API layer through which the frontend can communicate with backend functionality.
AWS Lambda — Backend processing
Lambda runs backend logic in response to API requests and other configured triggers without requiring me to manage a traditional application server.
Amazon DynamoDB — Data storage
DynamoDB provides a managed NoSQL database for application records and structured data.
Amazon EventBridge — Scheduled processing
EventBridge can trigger periodic tasks, such as scheduled risk calculations, when the relevant rules and targets are configured.
Amazon CloudWatch — Monitoring
CloudWatch supports operational visibility through logs and monitoring capabilities, helping developers investigate backend behavior and errors.
Amazon S3 — File storage
S3 can store uploaded photographs and reporting assets as part of the application's reporting workflow.
Amazon Bedrock — AI capabilities
Bedrock can support AI-assisted image analysis when an appropriate model, permissions, and application integration are configured.
Amazon SNS — Notifications
SNS can support email or other notifications when the required topics, subscriptions, permissions, and application triggers are configured.
Amazon Location Service — Route calculation
Amazon Location Service can provide route-calculation capabilities through its routing APIs when configured and integrated into the application's route workflow.
The important architectural principle is separation of responsibilities. The frontend handles user interaction, API Gateway exposes backend endpoints, Lambda processes requests, and DynamoDB stores application data. Supporting services can extend this foundation.
The availability of an AWS service does not, by itself, prove that its corresponding feature is fully integrated. Each workflow must be tested independently.
7. Why I Explored Serverless Architecture
As a solo developer, I wanted an architecture that would let me focus on application functionality without having to manage an entire traditional server infrastructure.
AWS managed services provide useful building blocks for this approach.
A serverless design can help separate individual responsibilities, simplify deployment workflows, and provide a foundation for future improvements.
However, serverless does not mean configuration-free. Developers must still understand permissions, environment variables, API contracts, error handling, service integrations, and monitoring.
Working on this project helped me appreciate those responsibilities much more clearly than simply reading about them.
8. The Development Journey
Step 1: Defining the Problem
I began by thinking about how flood-related information could be made more accessible and useful.
I narrowed the scope to a prototype rather than attempting to build a fully operational flood-prediction or emergency-warning system.
Step 2: Designing the Application
I considered the relationship between the user interface, backend endpoints, and persistent storage.
Separating these responsibilities helped me reason about the system and determine where the AWS services belonged.
Step 3: Integrating AWS
The next stage involved connecting the application to its cloud infrastructure.
This required attention to service configuration, permissions, request formats, and communication between components.
One important lesson was that configuring an individual service is only one part of the work. The complete request or processing workflow must be verified.
Step 4: Deploying the Application
I deployed the frontend using AWS Amplify.
The live application is available here:
Having a public deployment made it possible to share the project and demonstrate the result beyond my local development environment.
Step 5: Testing and Documenting
I focused on understanding how the architecture fits together and what would be required to make the application more reliable.
Documentation was an important part of this process because it forced me to explain why each component was needed and how the system was intended to work.
9. Challenges and Lessons Learned
Integrating Multiple Services
Connecting a frontend, API layer, backend functions, and database requires every component to agree on request formats, configuration, and permissions.
I learned to investigate the complete request flow rather than assuming that an error originated in the component where it first appeared.
AWS Configuration and Permissions
Cloud integrations depend on correct configuration and appropriate access permissions.
A deployment can succeed even when an individual API or backend workflow is still failing. Logs, configuration checks, and end-to-end tests are essential for identifying these problems.
Managing the Project Independently
As the only developer, I had to balance feature development, infrastructure, testing, and documentation.
This taught me to prioritize carefully and distinguish between planned functionality, implemented functionality, and functionality that has been tested successfully.
Thinking About Reliability
Environmental applications need to communicate their limitations clearly.
A flood-related interface should not create a false impression of accuracy or safety. Reliable data sources, appropriate validation, timestamps, and clear communication are essential before such an application can be relied upon for real-world decisions.
10. What Makes This Project Valuable to Me?
Chennai Flood Pulse helped me connect application development with practical cloud engineering.
I gained experience thinking about:
- Serverless application architecture.
- Frontend and backend integration.
- AWS service responsibilities.
- Cloud deployment and configuration.
- Debugging and monitoring.
- Testing the boundaries of a prototype.
- Communicating technical decisions through documentation.
Most importantly, I learned that building a useful application requires more than writing code. It requires understanding the problem, choosing suitable technologies, testing the system, and being transparent about what it can and cannot do.
11. Limitations and Future Improvements
Chennai Flood Pulse is a prototype, not a validated flood-warning service.
Its real-world usefulness depends on the quality and freshness of environmental data, the correctness of risk calculations, and the reliability of its reporting and notification workflows.
My next priorities would be:
- Integrating reliable environmental data sources.
- Improving location-specific information and data timestamps.
- Validating risk calculations against trusted observations.
- Testing the complete reporting and notification workflows.
- Improving monitoring and error handling.
- Evaluating usability and accessibility with potential users.
- Clearly communicating uncertainty and directing users to official emergency information when necessary.
I believe these steps are essential to moving from an interesting prototype toward a dependable environmental application.
12. Conclusion
Chennai Flood Pulse started with a question: how can cloud technology help make flood-related information more accessible and useful?
Building the project independently gave me an opportunity to explore that question through application development and AWS integration.
The journey taught me about serverless architecture, deployment, configuration, debugging, and the importance of validating technical claims.
I am proud to have taken the project from an idea to a publicly accessible prototype, and I see this as another step in my growth as a software developer.
One developer, one environmental challenge, and a practical opportunity to learn by building.
I welcome feedback from developers, AWS builders, mentors, and anyone interested in environmental technology. I would especially appreciate suggestions on the architecture, data reliability, and the next steps needed to make the application more useful.
Thank you to WeMakeDevs and AWS for creating opportunities for students to experiment, learn, and build solutions to real-world problems.
#AWS #WeMakeDevs #BharatBuilds #EnvironmentalHacks #Serverless #EnvironmentalTechnology
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article