Review skatespotsmap data management across multiple databases

[sktbrd]

Context

The current skatespotsmap flow depends on more than two databases/data sources. That increases maintenance overhead, makes debugging harder, and creates extra complexity for future feature work.

Problem

• Data for the map feature is spread across multiple databases
• Ownership and source of truth are not clear enough
• Sync, migration, and consistency risks increase as the feature grows
• The current setup deserves a dedicated architecture review before it becomes harder to change

Goals

• Audit all databases/data stores currently used by skatespotsmap
• Document what each one stores and why it exists
• Define a clearer source of truth for spot/map-related data
• Identify opportunities to reduce the number of databases or simplify the integration boundaries
• Propose a migration/refactor path with minimal product risk

Acceptance criteria

• Current data architecture mapped and documented
• Pain points and duplication risks identified
• Recommendation written for consolidation or clearer separation of responsibilities
• Follow-up implementation tasks created if structural changes are needed