The Journey of a Waste Shouldn't End in a Landfill: Building EcoRoute with AWS
EcoRoute is an intelligent reverse logistics platform for waste collection, optimized routing, facility verification, and transparent settlement. Built with Next.js, React, FastAPI, and AWS, it combines capacity-aware allocation, geospatial validation, photographic evidence, and SHA-256 hash chains to improve traceability and accountability. It connects physical waste movement with digital records, making recycling workflows more efficient and transparent from doorstep collection to final destination.
What happens when waste collection becomes a distributed-systems problem? Our journey into intelligent routing, evidence-based verification, cloud architecture, and making physical operations digitally traceable.
The Most Interesting Thing About Waste Is What We Don't See
Imagine throwing away paper, metals or an electronic waste. Someone collects it. Perhaps it reaches a sorting centre. Perhaps it is recycled.
But who collected it? How much material reached the facility? Does the recorded weight match what the collector reported? And if money changes hands, can everyone understand how the final amount was calculated?
A bottle has a physical journey, but the information describing it can become fragmented along the way.
That gap became the starting point for EcoRoute.
Our goal was to connect collection, transportation, verification, and settlement into one traceable digital journey.
How do you prove that a waste collection actually happened the way the system says it did?
Dev Quest 1 — A Pickup Request Is Easy. Everything After It Is Interesting.
A customer selects a waste category, enters an approximate quantity, and requests a pickup. But the nearest collector might lack sufficient vehicle capacity, handle the wrong waste stream, or already have a route that makes another assignment inefficient.
Choosing the nearest person is easy. Choosing an eligible collector without unnecessary detours is harder.
EcoRoute uses Next.js, React, and TypeScript for the frontend, with Python and FastAPI handling backend requests and business logic. Leaflet and OpenStreetMap support geographic visualisation.
Our routing logic checks waste-stream compatibility and vehicle capacity, then uses the Haversine formula to estimate geographic distances and a minimum-detour insertion strategy to evaluate new pickups.
Since the Haversine formula does not account for traffic or road closures, geographic distance is an input to route planning, not a complete model of real-world travel.
We wanted EcoRoute to answer a better question than “Who is closest?”
Which eligible collector can take this pickup, and how can it fit into the collection journey sensibly?
Dev Quest 2 — The Database Is Not the Journey
A booking is only the beginning. Collection, load sealing, transportation, facility verification, and settlement are distinct stages of one operational process.
EcoRoute's backend separates API routers, business services, workflow logic, and persistence responsibilities. Deterministic state-transition logic controls how the workflow progresses.
Amazon DynamoDB stores operational records, while Amazon S3 stores photographs and audit-related artifacts. Boto3 integrates AWS with the Python backend, and Amazon Cognito supports authentication in the configured flow.
A completed status is not the same as evidence that a collection happened. A photograph without a corresponding load record is difficult to interpret, while a completed status without supporting evidence may be insufficient to investigate discrepancies.
The engineering challenge is connecting operational records and evidence to the same journey.
Dev Quest 3 — The 6 AM Problem: Production Logic Meets Demo Reality
EcoRoute's intended operating model allocates collection routes and assignments at 6 AM every day. During a daytime demonstration, however, waiting for the next run would be impractical.
So, for the demo, we trigger allocation manually.
The allocation logic still evaluates collector eligibility, vehicle capacity, waste compatibility, and route-planning constraints. The manual trigger simply allows us to demonstrate the process on demand.
This revealed an important distinction: the scheduling mechanism determines when a process runs, while the allocation algorithm determines what happens.
A manual trigger is useful for testing, but it does not prove that a production scheduler is deployed and running. Production automation and testability must coexist, and a demonstration should be honest about the difference.
Dev Quest 4 — The Collector Says 5.0 kg. The Facility Says 5.1 kg.
A collector reports 5.0 kg of material. At the receiving facility, the recorded weight is 5.1 kg.
Is something wrong? Not necessarily. The difference is 0.1 kg, or 2% relative to the collector's reported weight. It could arise from measurement variation or handling, although the appropriate tolerance depends on the material and weighing process.
EcoRoute's facility-verification workflow connects a sealed load to its collection records using a unique load code, such as LD-7F5C0B. This links the relevant stops, waste stream, aggregated weight, and intended destination.
At the facility, the operator identifies the load, records its weight, and submits photographs of the handover and weighing record.
The workflow checks load identity, the configured facility geofence, duplicate image submissions, and weight differences. The geofence is configured at 300 metres, while the example weight-verification policy uses a 15% tolerance.
The 2% difference falls within that configured threshold. This is a system parameter, not a universal standard for waste verification.
Photographs are stored in S3, and operational records are maintained in DynamoDB. SHA-256 can detect identical files but not every visually similar image; GPS coordinates provide a location signal, not absolute proof of an event.
Can we explain the difference between what was collected and what was received?
Dev Quest 5 — Can a Hash Help Us Trust a History?
A database tells us what it currently stores. An audit mechanism helps us examine whether its recorded history remains consistent.
EcoRoute uses a SHA-256 hash chain to link important workflow events. Each event's hash incorporates its contents and its connection to the preceding event. If an earlier event changes without the subsequent chain being updated appropriately, verification can detect an inconsistency.
We also store audit-related artifacts and hash anchors in S3.
However, a hash chain is not automatically an immutable ledger. Someone able to rewrite the entire chain could potentially recompute its hashes. Stronger guarantees depend on how the chain is anchored, who can modify those anchors, and how verification is performed.
The same care applies to OTP verification. EcoRoute's configured workflow uses a four-digit code represented by a SHA-256 hash, with a three-strike attempt limit. Because four-digit codes have a small search space, hashing alone is insufficient; attempt limits, expiration, and appropriate access controls remain important.
Authentication validates participants, state-transition logic controls workflow progression, and the hash chain helps examine the consistency of recorded history. Each solves a different problem.
No single mechanism proves everything. In engineering, precise claims are part of building trust.
Dev Quest 6 — Designing for the Person Holding the Bag of Waste
Field workers may be carrying materials, navigating between pickups, or dealing with unreliable connectivity. A complicated interface can quickly become an obstacle.
EcoRoute combines a web interface for detailed operational tasks with a message-driven interface for supported field operations. The web portal provides structured collection information, while the WhatsApp-oriented workflow aims to simplify selected tasks.
This also raises an accessibility question: can workers using keypad phones participate without navigating a complex web interface? Such a phone must support WhatsApp, and a simulator demonstrating the interaction is not equivalent to a fully operational production messaging integration.
The best interface is not always the one with the most features. It is the one that lets the intended user complete the task reliably.
Dev Quest 7 — Where AWS Fits Into the Story
We did not want AWS to be a collection of logos on an architecture slide. Each service needed a clear responsibility.
AWS Open Source Stack
Cedar Policy Language (cedar-policy): Supports policy-based access control. Its policies govern collector eligibility, waste-stream and geographical-zone compatibility, facility-specific proof submission, hazardous-waste handling, and administrator-only dispute resolution.
Boto3 and Botocore: Provide Python integration with AWS, supporting DynamoDB transactional writes, Global Secondary Index queries, S3 presigned URL generation, and queue operations.
AWS Services
Component | Responsibility |
|---|---|
Next.js, React, TypeScript | Web interface |
Python and FastAPI | API and business logic |
Leaflet and OpenStreetMap | Geographic visualisation |
Amazon DynamoDB | Operational records, transactions, and indexed queries |
Amazon S3 | Photographs, audit artifacts, and cryptographic hash anchors |
Amazon SQS | Asynchronous message processing, FIFO ordering, and dead-letter handling |
Amazon Cognito | Identity, authentication, and role-based access control |
Amazon SNS | Administrative alerts for operational anomalies |
Amazon EventBridge | Scheduled operational workflows |
Amazon CloudWatch | Operational monitoring |
Boto3 and Botocore | Python integration with AWS |
Cedar Policy Language | Policy-based access control |
Routing, state-transition, and ledger modules | Application-specific rules |
SHA-256 hash-chain logic | Audit-history integrity checks |
AWS Amplify | Frontend deployment and hosting |
AWS Lambda | Serverless backend compute |
AWS provides infrastructure, but application logic defines the business rules. DynamoDB does not decide whether a collector is eligible for a waste stream, and S3 does not prove that a photograph corresponds to the correct load.
We also learned to distinguish configured infrastructure from verified end-to-end integrations. Creating a queue or notification topic does not prove that application events reliably pass through it. Similarly, configuring a policy store does not establish that every authorization decision is evaluated by that service.
Scheduled jobs and messaging integrations must also be tested before we claim they operate automatically.
Cloud services provide building blocks. Reliable workflows depend on how those blocks are connected and validated.
Dev Quest 8 — From Verified Material to an Accountable Outcome
Verification is not the end of the journey. The system must also record what happens to the resulting value.
EcoRoute's ledger logic supports entries associated with collection fees and recyclable-material valuation. The configured Value Unit distribution allocates:
- 70% to the household
- 20% to the collector
- 10% to the platform reserve
For 100 Value Units, that means 70, 20, and 10 Value Units respectively. This is the configured distribution model, not a measured financial outcome.
The engineering challenge is ensuring that entries remain traceable to verified transactions and follow applicable accounting rules. Retries and partial failures must be handled carefully to avoid duplicate entries or inconsistencies between operational status and settlement.
A final verification summary can bring together load identity, collection records, facility measurements, supporting evidence, and audit information. Where certificate generation is implemented, it can present those details in a convenient format.
However, a generated certificate or SHA-256 root hash does not independently prove that recycling occurred or establish regulatory approval. Claims such as “official CPCB-compliant seal” require substantiation beyond an application-generated document.
Looking ahead, we would strengthen route evaluation with road-network travel times, improve recovery from partial failures, expand end-to-end integration testing, and measure route-distance reduction, verification rates, and processing time. Those measurements would let us evaluate impact rather than assume it.
The Lesson We Are Taking Away
At the beginning, we could have defined success as a customer being able to book a pickup.
But a booking is only a promise.
The collector still needs to arrive. The material needs to be collected and delivered. The quantity needs to be checked, settlement must follow defined rules, and the recorded history must make sense when examined later.
EcoRoute became a project about connecting physical operations to digital records, combining geographic constraints with workflow validation, and using cloud infrastructure to support a process in which evidence matters.
The most important part is not that we used a particular framework or AWS service. It is the question behind every technical decision:
How can we make a complex, real-world process easier to coordinate and easier to verify?
A waste-management system should not stop caring about a material the moment it leaves someone's doorstep. It should follow the journey, preserve the evidence, and make the outcome understandable.
Every waste stream needs a destination. Every handover needs evidence. And every journey deserves a record that can be examined—not merely trusted.
That is EcoRoute.
Built with Next.js, React, TypeScript, Python, FastAPI, Boto3, Amazon DynamoDB, Amazon S3, Amazon SQS, AWS Amplify, AWS Lambda, Amazon Cognito, Amazon SNS, Amazon EventBridge, and Amazon CloudWatch, with policy-based access control using Cedar.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article