Designing a Scalable Relational Schema
Defining how players, turfs, match‑groups, bookings, and reviews relate was more complex than it first appeared. We needed junction tables (e.g.,

match_participants

) to represent many‑to‑many relationships, and careful use of foreign keys to enforce referential integrity. Balancing normalization (to avoid redundant data) with query performance took significant iteration.

Establishing Table Connections & Migrations
Writing and maintaining database migrations (using Flask‑Migrate/Alembic) was error‑prone at first: missing constraints, circular dependencies, and order‑of‑execution issues forced us to drop and re‑create tables multiple times. We had to learn how to write “offline” batch migrations and ensure that each change would apply cleanly in both our local and production environments.

Optimizing Query Performance
As we joined multiple tables to display composite data (e.g., a turf’s upcoming bookings alongside owner info and location), we ran into N+1 query problems. Integrating Flask‑SQLAlchemy’s

joinedload

and writing custom index hints improved response times drastically, but required careful profiling and understanding of the ORM’s lazy/eager loading options.

Handling Geospatial Data in the Database
To support proximity searches (“find turfs within 5 km”), we experimented with storing latitude/longitude as plain floats versus using PostGIS. The latter offered built‑in indexing and “ST_Distance” calculations, but added complexity in deployment. We settled on PostGIS, learning to define geometry columns and spatial indexes.

Integrating the Map API
Consuming Google Maps (and later Mapbox) APIs in the frontend meant managing API keys, usage quotas, and billing. We built a small Flask endpoint to proxy geocoding requests, which solved CORS issues and hid our secret keys. Implementing “autocomplete” for address search required debouncing user input and handling edge cases where partial addresses returned ambiguous coordinates.

Synchronizing Frontend & Backend Data
Ensuring that turf availability on the map reflected real‑time booking status demanded WebSocket integration. We extended our Flask app with Flask‑SocketIO, wiring events for “new booking” and “booking canceled,” and writing client‑side listeners to update both the map markers and availability panels instantly.

• Error Handling & Fallbacks
  Map API outages or rate limits caused search failures—so we built graceful fallbacks, caching recent geocoding results in Redis and displaying a simple list view if the map failed to load. This redundancy increased complexity but was essential for a smooth user experience.

Time Constraints & Iteration
Working within a 36‑hour hackathon window meant prioritizing core features over polish. We had to defer advanced map overlays (heatmaps of popular slots) and deep analytics, focusing instead on a minimal viable integration that showcased real‑time turf discovery and booking functionality.

Each of these challenges strengthened our understanding of database design, API integration, and real‑time web architectures—key skills for delivering a robust, hackathon‑ready sports platform.