# Architecture Decisions (ADR) --- **Document Version:** 1.0 **Project:** Student Bazaar **Document Type:** Architecture Decision Record (ADR) **Status:** Approved **Last Updated:** 28 June 2026 **Author:** Nemmi Tangha --- # 1. Purpose This document records the major architectural and technical decisions made during the planning and development of Student Bazaar. Its purpose is to explain **why** specific technologies, design patterns, and implementation approaches were selected. These decisions serve as the project's technical foundation and should guide all future development. --- # 2. Technology Stack ## Backend Framework **Decision:** Python Flask ### Reason * Internship requirement specifies Flask. * Lightweight and modular. * Excellent Blueprint support. * Large ecosystem of extensions. * Well suited for medium to large web applications. --- ## Database **Decision:** MySQL ### Reason * Reliable relational database. * Strong support for structured relationships. * Excellent compatibility with Flask. * Suitable for transactional applications. --- ## ORM **Decision:** Flask-SQLAlchemy ### Reason * Cleaner database operations. * Simplifies relationships. * Easier maintenance. * Reduces repetitive SQL code. * Industry standard for Flask applications. --- ## Frontend **Decision** * HTML5 * CSS3 * Bootstrap 5 * JavaScript ### Reason * Responsive design. * Easy maintenance. * Fast development. * Consistent UI components. --- # 3. Architectural Pattern ## Decision Feature-Based Modular Architecture with a Service Layer. ### Reason Instead of placing all application logic into a few large files, the project is divided into independent feature modules. Each feature manages its own routes, business logic, forms, and models. Benefits include: * Better organization * Easier maintenance * Improved scalability * Simpler testing * Easier onboarding for future developers --- # 4. Request Flow Every request follows the same processing pipeline. Browser ↓ Flask Route (Blueprint) ↓ Service Layer ↓ Database Model ↓ MySQL Database ↓ Response Business logic must remain inside the Service Layer. Routes should only receive requests and return responses. --- # 5. User Model ## Decision A single **Student** account acts as both buyer and seller. ### Reason Students naturally perform both roles. A user becomes: * Seller when creating a listing. * Buyer when making an offer. This removes unnecessary role switching and simplifies the authentication system. --- # 6. Marketplace Model ## Decision One product listing belongs to one student. Each listing contains: * Product Information * Images (1–7) * Status * Price * Expiration Date Listings may have one of the following statuses: * Available * Reserved * Sold * Expired * Removed --- # 7. Image Upload Policy ## Decision Each listing supports: * Minimum: 1 image * Maximum: 7 images ### Reason Allows flexibility while preventing excessive storage usage. --- # 8. Bargaining System ## Decision Negotiation is handled through a structured Offer System rather than normal chat. Workflow: Seller Price ↓ Buyer Offer ↓ Seller Counter Offer ↓ Buyer Counter Offer ↓ Offer Accepted ↓ Final Agreed Price ### Reason Provides structured negotiation. Maintains offer history. Allows future analytics. Separates negotiation from messaging. --- # 9. Chat System ## Decision One chat exists for each product listing. The conversation becomes active only after both students exchange their first message. Each conversation includes: * 10 free messages Rewarded advertisements unlock: * 5 additional messages Premium users receive unlimited messaging. ### Reason Provides fair communication limits. Supports advertisement-based monetization. Encourages Premium subscriptions without preventing normal marketplace use. --- # 10. Meet-up Scheduler ## Decision Meet-up scheduling becomes available only after an offer is accepted. Students can: * Suggest Date * Suggest Time * Suggest Location * Accept * Reject * Reschedule ### Reason Ensures meet-up planning occurs only after successful negotiation. --- # 11. Payment Handling ## Decision Student Bazaar does not process payments. ### Reason The platform only connects buyers and sellers. Financial responsibility remains entirely with the users. No payment gateway will be implemented in Version 1. --- # 12. Advertisement Strategy ## Decision Two advertisement types will be implemented. ### Banner Advertisements Displayed on: * Homepage * Dashboard * Search * Product Details ### Rewarded Advertisements Displayed when: * Chat limit is reached. Watching one advertisement unlocks: * Five additional chat messages. --- # 13. Premium Membership Premium users receive: * Unlimited Messaging * Ad-Free Browsing * Featured Listings * Priority Support ### Reason Provides a sustainable monetization model while improving the user experience. --- # 14. Seller Dashboard Every student who creates listings gains access to a Seller Dashboard. Dashboard includes: * Listing Management * Product Statistics * Views * Favorites * Chats * Offers * Sales Analytics --- # 15. Notification System Notifications are generated for: * Messages * Offers * Counter Offers * Accepted Offers * Meet-up Updates * Listing Expiration * Reports * Premium Reminders ### Reason Keeps students informed without requiring constant manual checking. --- # 16. Security Decisions Version 1 will include: * Password Hashing * Email Verification * CSRF Protection * Input Validation * SQL Injection Protection * XSS Prevention * Secure Session Management Future versions may include: * Multi-Factor Authentication * OAuth Login * College Email Verification --- # 17. Future Architecture The architecture is designed for future expansion. Potential future modules include: * Mobile Application * AI Recommendation Engine * Payment Integration * QR Verification * Push Notifications * College Verification The modular architecture allows these features to be added without major restructuring. --- # 18. Conclusion The architectural decisions documented here establish a scalable, maintainable, and production-ready foundation for Student Bazaar. All future development should follow these decisions unless a formal revision to this document is approved.