JalSetu: Building a Fair Water Tanker Dispatch System with AWS Serverless
How we built an AWS-powered water tanker dispatch platform to make municipal water distribution fairer, delivery records verifiable, and allocation decisions transparent—and the engineering challenges we faced along the way.
Software Developer
JalSetu: Building a Fair Water Tanker Dispatch System with AWS Serverless
What we learned while building a transparent, fairness-driven water tanker dispatch platform for AWS Environmental Hacks.
The problem: Water scarcity is also a distribution problem
In many Indian cities, residential colonies depend on municipal water tankers, particularly during periods of extreme heat. When demand exceeds supply, deciding who receives water first becomes a critical challenge.
But how are these decisions made? Can residents understand why another colony received a tanker first? Can dispatchers verify that a delivery actually happened? And when something goes wrong, is there an auditable record of what happened?
We wanted to explore these questions by building JalSetu — Fair Water Tanker Dispatch, a platform designed to make water allocation more equitable, delivery records more verifiable, and dispatch decisions more transparent.
Our central idea was simple: access to water should be prioritized by need, not influence.
Designing a fairer dispatch system
JalSetu uses a fair-queue model that ranks colonies according to recent water availability per person, accounting for tanker deliveries and piped-water supply.
Instead of presenting an unexplained queue position, the system is designed to provide reasons for prioritization in both Hindi and English.
The platform also considers practical dispatch constraints. Larger colonies may require multiple tanker loads, and a tanker should never be assigned to two colonies simultaneously.
We built the system around four goals:
- Fair allocation: Prioritize colonies based on recent water availability and need.
- Verifiable deliveries: Record delivery information, GPS data and photographs, alongside confirmation from the receiving colony representative.
- Public accountability: Maintain records that make dispatch decisions easier to inspect and disputes easier to investigate.
- Early intervention: Use temperature forecasts to help identify colonies that may run short of water.
These features are intended to support a more accountable distribution process, rather than simply moving an existing manual workflow online.
The technology stack
We chose AWS serverless services to build the backend and supporting infrastructure without having to manage application servers.
Here is how the main components fit together.
Amazon API Gateway and AWS Lambda
Amazon API Gateway exposes the application's HTTP API, while Python-based AWS Lambda functions implement the application logic.
The backend handles fair ranking, dispatch operations, delivery verification and heat-warning workflows. Keeping the business logic in Lambda functions also makes individual operations easier to develop and test.
Amazon DynamoDB
DynamoDB stores the application's operational records, including colony information, tanker assignments, dispatches, delivery records and related audit data.
One important design consideration was consistency. If two requests attempt to assign the same tanker concurrently, the system must prevent conflicting assignments.
We used conditional writes and transactional operations to protect critical state changes and enforce these constraints at the data layer.
Amazon EventBridge
Dispatch-related workflows can run on a schedule through Amazon EventBridge. This supports automated processing of eligible tanker releases and other time-based operations without requiring a continuously running server.
Amazon S3 and Amazon SNS
Amazon S3 stores delivery photographs and related evidence. Amazon SNS supports configured notifications for operational failures and alerts.
Together, these services provide building blocks for delivery documentation and operational awareness.
Amazon CloudFront and AWS SAM
The web frontend is deployed as a static application using S3 and CloudFront. We used AWS SAM to define and deploy the serverless infrastructure, with AWS CLI-based deployment automation.
This gave us a repeatable way to package and deploy the application and its infrastructure.
What fought back: Engineering challenges
Building with serverless services does not eliminate infrastructure complexity. It changes where that complexity appears.
Here are some of the challenges we encountered during development.
1. Preventing conflicting dispatches
Fair ranking is only part of the problem. The system must also preserve correctness when multiple operations happen at once.
A tanker that has already been assigned should not become available for another assignment simply because two requests arrive close together.
This is why conditional writes and transactional state changes mattered. They helped us move important constraints into the data layer instead of relying exclusively on frontend checks.
Lesson: Business rules that protect shared resources should be enforced by the backend and database, not just by the user interface.
2. Navigating DynamoDB capacity constraints
Our development process exposed practical considerations around DynamoDB capacity and data modelling. Capacity settings affect how tables behave under load, while indexes can introduce additional storage and throughput requirements.
We also had to consider how conditional transactions behave when a state change cannot be applied.
Lesson: Choosing a managed database does not remove the need to understand access patterns, capacity limits, transactional behavior and failure cases.
3. Getting deployment configuration right
Serverless deployments involve more than application code. IAM permissions, parameter names, resource configuration, environment variables and frontend hosting settings all need to agree.
We encountered configuration issues involving parameter naming, deployment permissions and CloudFront delivery. These reinforced the importance of validating the infrastructure definition and deployment process, rather than treating deployment as a final one-click step.
Lesson: Infrastructure-as-code is most useful when it is reproducible, consistently configured and tested alongside the application.
4. Designing for accountability, not just data collection
Recording a GPS coordinate and photograph is useful, but neither independently proves the exact quantity of water delivered.
That distinction matters for a public-service system. Evidence collection should make discrepancies easier to investigate without claiming more certainty than the data supports.
Our approach combines driver-submitted evidence with confirmation from the receiving colony representative. More rigorous quantity verification remains an important area for further development.
Lesson: A transparent system should communicate what it can verify, what it merely records, and where human review is still necessary.
Testing the system
Our hackathon submission documents 40 automated tests, alongside end-to-end checks of application user journeys.
We also considered failure handling, access control, deployment configuration and consistency during dispatch updates.
Testing is especially important in a system where an incorrect state transition could affect which colony receives a limited resource.
The next stage would require broader concurrency testing, security review, operational monitoring and field validation to establish how the system performs under realistic municipal workloads.
My role in the project
As team lead, I focused on problem research, solution design and product direction.
I identified the fairness and accountability gaps we wanted to address, defined the fair-queue concept and its explanations, and planned the delivery-verification workflow and public audit requirements.
I also helped establish the feature scope, safeguards and demonstration flow, while coordinating the overall project direction and final submission.
The team worked across backend and AWS infrastructure, frontend development, accessibility and testing to bring the system together.
What comes next?
JalSetu is a foundation for exploring more transparent water distribution, but its real-world impact must be measured rather than assumed.
Our next priorities would be:
- Pilot testing with municipal authorities and residential communities.
- Measuring waiting times and disparities in water availability before and after introducing fair allocation.
- Improving the reliability of delivered-quantity verification.
- Evaluating heat-warning accuracy against actual water shortages.
- Strengthening production security, monitoring and recovery procedures.
These steps would help determine whether the system improves distribution outcomes, not merely whether it functions technically.
Final thoughts
JalSetu began with a question about fairness: how can we make sure that limited water reaches the communities that need it most?
Building it helped us connect product design, backend consistency, serverless architecture and public accountability in one system. It also reminded us that real-world engineering is not just about selecting cloud services or getting an application to run. It is about handling edge cases, making decisions explainable and being honest about limitations.
Our biggest takeaway: technology can help make public infrastructure more transparent, but trust comes from verifiable processes, reliable engineering and measurable outcomes.
Explore the project
- GitHub repository: https://github.com/saminadamn/tanker-dispatch
- Hackathon submission: https://www.wemakedevs.org/samina
JalSetu was built for AWS Environmental Hacks.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article