1.

Application Architecture
You have to choose one of the following architectures and explain how your project follows that
model:

1. Microservices Architecture
○ The application is split into small, independent services (e.g., an issue-reporting
service, a volunteer-matching service).
○ Each service runs separately and communicates using APIs.
○ Example: Uber’s system has separate services for ride requests, payments, and
maps.
2. Event-Driven Architecture
○ The system reacts to events (e.g., when a user reports an issue, a notification is
sent to volunteers).
○ Components communicate using event messages (like a chat system where a
new message appears in real-time).
○ Example: WhatsApp notifications when a new message arrives.

3. Serverless Architecture
○ The backend runs on cloud-based functions that execute when needed.
○ No need to manage servers; the system scales automatically.
○ Example: When a user submits an issue, a cloud function processes and stores
it.
4. Monolithic Architecture
○ The entire application is built as a single unit (everything runs together in one big
codebase).
○ Easier to develop but harder to scale.
○ Example: A simple blog website where everything (login, posts, comments) is in
one big system.

Diagrams to Include:
● Use Case Diagram: Shows different users (citizens, volunteers, admins) and what
actions they can perform.
● Class Diagram: Defines system objects (Issue, User, Volunteer) and their relationships.
● Data Flow Diagram (DFD): Shows how data moves (e.g., how an issue report is
processed).
● Component Diagram: Displays different system modules and their connections.
● Sequence Diagram: Shows the step-by-step flow of an action (e.g., issue reporting
process).
● Deployment Diagram: Explains where and how the system runs (e.g., on AWS, local
servers).

2. Database
2.1 ER Diagram (Entity-Relationship Diagram)
The ER Diagram represents how different entities (tables) in the database interact with each
other. Here are the key entities and their relationships:

Main Entities & Relationships:

1. Users → Can report issues, submit complaints, and resolve issues.
2. Issues → Created by users, resolved by volunteers, assigned status.
3. Volunteers → Users with skills to resolve issues, linked to rewards.
4. Complaints → Filed by users, handled by authorities.
5. Rewards → Given to volunteers based on their contributions.

Entity Relationships:
1. One User → Can report multiple issues (1:N).
2. One Issue → Can be assigned to one or more volunteers (N:M).
3. One User → Can file multiple complaints (1:N).
4. One Volunteer → Can receive multiple rewards (1:N).
3. Data Exchange Contract
Describes how different system parts communicate and share data.

1. Frequency of Data Exchanges

○ How often data is sent/received (real-time, hourly, daily).
○ Example: Notifications are real-time, but reports are updated every few hours.
2. Data Sets
○ What kind of data is exchanged.
○ Example: User details, issue reports, status updates, volunteer assignments.
3. Mode of Exchanges
○ How the data is transmitted between components.
○ Example:
■ API (Application Programming Interface): Used for communication
between frontend and backend.
■ File Transfer: CSV files exported for reports.
■ Message Queue (MQTT/Kafka): Used in event-driven systems to send
real-time messages.

Final Steps:
● Choose the architecture that best fits your Next Step project.
● Create the required diagrams to explain how the system works.
● Define how data is stored and shared between different parts of the system.

Data Exchange Contract

1. Frequency of Data Exchanges
Data exchanges occur at different frequencies based on the nature of the interaction:

● Real-time:
○ User registration & authentication
○ Issue reporting & updates
○ Complaint filing & tracking
○ Reward allocation updates
○ User comments on issues
● Scheduled (Periodic):
○ Leaderboard updates (e.g., every 24 hours)
 ○ Summary reports for authorities (e.g., daily or weekly reports on complaints and
issues)
● Event-Triggered:
○ Notifications (when a volunteer picks up an issue or a complaint status is
updated)
○ Status changes (e.g., issue resolved, complaint escalated)

2. Data Sets
The platform handles multiple types of structured data sets:

Users
● User ID
● Name
● Email
● Phone Number
● Role (User, Volunteer, Authority)
● Location
● Skills (for volunteers)
● Rewards Earned

Issues
● Issue ID
● User ID (Reporter)
● Title
● Description
● Category (Road, Pipeline, Electrical, etc.)
● Location
● Status (Pending, In Progress, Resolved)
● Assigned Volunteer(s)
● Created At
● Updated At

Complaints
● Complaint ID
● User ID (Complainant)
● Title
● Description
● Category (Cybercrime, Theft, Police, Government)
● Assigned Authority
● Status (Submitted, Under Review, Resolved)
 ● Created At
● Updated At

Rewards
● Reward ID
● Volunteer ID
● Points Earned
● Reward Level (Gold, Silver, Bronze)
● Issued Date

Comments & Updates

● Comment ID
● User ID
● Issue/Complaint ID
● Comment Text
● Timestamp

Leaderboard
● User ID
● Points
● Rank
● Last Updated

3. Mode of Exchanges
3.1 API-Based Exchanges (Primary Mode)
APIs will be used for most interactions in a microservices-based architecture:

● RESTful APIs (for synchronous operations)

● WebSockets (for real-time updates like notifications and issue updates)

Endpoints Examples:

1. User Authentication & Management

○ POST /api/auth/register → User registration
○ POST /api/auth/login → User login
○ GET /api/users/{id} → Fetch user profile
2. Issue Reporting & Updates
○ POST /api/issues → Report a new issue
○ GET /api/issues/{id} → Get issue details
○ PUT /api/issues/{id} → Update issue status
3. Complaint Filing
○ POST /api/complaints → File a new complaint
○ GET /api/complaints/{id} → Get complaint details
 4. Volunteer Assignments & Rewards
○ POST /api/volunteers/{id}/accept-issue → Volunteer accepts
issue
○ GET /api/rewards/{id} → Fetch rewards
5. Leaderboard
○ GET /api/leaderboard → Fetch top contributors

3.2 Event-Driven Communication (Asynchronous Mode)

For notifications and background processing, message queues and event-driven
mechanisms will be used:

● Kafka / RabbitMQ (Message Queue) → For handling background notifications,

reward calculations, and leaderboard updates.
● Firebase Cloud Messaging (FCM) / WebSockets → For real-time push
notifications.

Example Events:

● issue.created → Notify volunteers about a new issue.

● issue.assigned → Notify a user when a volunteer picks up an issue.
● reward.earned → Notify a volunteer when they earn a reward.

3.3 File-Based Exchanges (Reports & Data Exports)

Certain data exchanges, like report generation and bulk uploads, will be handled via file-based
exchanges:

● Format: CSV, JSON, PDF

● Example:
○ Daily report on open complaints → Sent to authorities as a CSV file
○ Monthly leaderboard summary → Exported as a PDF report