Hinton Farmers Market

HintonMarket is a farmers market management system built for a fictional town called Hintonville, which converted an unused parking lot into a weekly outdoor market. The system replaces manual coordination with a structured platform that handles everything from vendor registration to stall booking to waitlist management.

The project was built by a team of four over two deliverables. The first focused on a fully in-memory prototype. The second introduced persistent SQLite storage and a new role for market operators who can manage bookings on behalf of vendors. I served as team lead across both deliverables.

The platform supports three user types, each with their own interface and responsibilities.

• Vendors can browse available market dates, book stalls by category (food or artisan), cancel bookings, join a waitlist when a category is full, and view a personal dashboard showing their current bookings, waitlist positions, and compliance status
• Market operators can perform all booking and cancellation actions on behalf of any vendor, giving them a management layer above the vendor-facing interface
• Administrators have full system oversight: account configuration, report generation, and system-wide settings
• The system enforces capacity limits (20 food stalls and 10 artisan stalls per market day), booking deadlines, and a 30-minute session timeout
• Waitlists are organized per category and per market week, with automatic FIFO notifications when a spot opens up

As team lead, I coordinated task assignments, integration milestones, and the overall architecture review across both deliverables. On the implementation side, my ownership was the complete waitlist subsystem.

This included defining the core data entities (Vendor, MarketDate, WaitlistEntry, and Waitlist), building the WaitlistControl layer that handles joining and leaving the queue, implementing the FIFO ordering logic so vendors are always notified in the order they joined, and building the WaitlistView interface that shows each vendor their current queue position.

For the second deliverable, I refactored the entire waitlist subsystem to use the Bridge design pattern, which cleanly separates the business logic from the storage layer. This meant the same waitlist code could run against either the original in-memory store or the new SQLite database without any changes to the application logic. I also migrated all waitlist operations to raw SQL queries and ensured that waitlist data and notifications survive a program restart.

The system is structured in four layers: a View layer for all user interfaces, a Control layer for business logic, a Model layer for the data entities, and a Repository layer (DataRepository) that acts as the single access point for all stored data. This separation keeps each layer focused on one responsibility and makes testing and debugging straightforward.

The Bridge pattern introduced in the second deliverable wraps the Repository behind an interface, so switching from in-memory to SQLite is a configuration change rather than a code rewrite. This makes the architecture extensible: adding a new storage backend in the future requires no changes to the business logic above it.