SharePlate: Event-Driven Redistribution Network with AWS
Every day, perfectly usable food can become waste simply because the right organization was not able to find it in time. A restaurant may have 50 surplus meals after an event. A community kitchen may be serving people only a few kilometers away. A supermarket may have products approaching their redistribution window. The problem is often not the absence of food or organizations willing to help—it is the lack of a system that can coordinate them quickly.
Designing SharePlate as a Serverless System
The architecture is built around AWS managed services so that the application does not need a fleet of continuously running backend servers.
At a high level, the system can be viewed as several layers:
React Application
↓
Amazon Cognito
↓
Amazon API Gateway
↓
AWS Lambda
↓
Amazon DynamoDB / Amazon S3
↓
Event-driven processing + Amazon CloudWatch
↓
Amazon Cognito
↓
Amazon API Gateway
↓
AWS Lambda
↓
Amazon DynamoDB / Amazon S3
↓
Event-driven processing + Amazon CloudWatch
Each component has a focused responsibility.
Application Layer
The frontend can be built using React and AWS Amplify, providing different interfaces depending on the user's role.
A provider might see active food listings and pickup requests, while a recipient organization sees nearby opportunities and its pending collections. Volunteers can receive assigned pickup tasks, and administrators can monitor the overall system.
This separation allows the same platform to support different participants without exposing unnecessary functionality to each role.
Turning APIs into Independent Operations
The backend exposes application functionality through Amazon API Gateway.
Instead of building one large backend service, SharePlate can divide its operations into focused API endpoints.
Examples include:
POST /listingsCreate a surplus listing.
GET /listingsDiscover available surplus food.
POST /requestsRequest a particular listing.
PATCH /pickups/{id}Update pickup progress.
POST /deliveriesConfirm successful redistribution.
Each operation can invoke a dedicated AWS Lambda function.
This approach keeps business logic modular and allows individual parts of the application to scale independently.
Making the Architecture Event-Driven
Some operations should happen immediately. Others can happen asynchronously.
This distinction is important for SharePlate.
Consider what happens after a provider creates a listing.
The user only needs confirmation that the listing was successfully created. The system does not necessarily need to perform every downstream operation before returning the response.
The workflow can instead become:
Listing Created
↓
Event Generated
↓
Validation / Processing
↓
Candidate Matching
↓
Organization Notification
↓
Event Generated
↓
Validation / Processing
↓
Candidate Matching
↓
Organization Notification
The same principle can be applied after delivery:
Delivery Confirmed
↓
Impact Event
↓
Metrics Updated
↓
Dashboard Refreshed
↓
Impact Event
↓
Metrics Updated
↓
Dashboard Refreshed
AWS event-driven services can be introduced here to decouple these operations and prevent one slow process from blocking the main user request.
This makes the architecture easier to extend as new workflows are introduced.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article