CLIENT
Since 2019, SHOWX worked as the sole company building the first viable way for musicians to sell tickets directly to their fans and own their first-party data. Over $100k in tickets were sold on SHOWX while the platform was used to create concerts across the US including over 150 bands booking performances at SXSW.
CHALLENGE
Like most startups, SHOWX had to grow and adapt quickly to keep up with the music industry standards. Speed came at a cost: tech debt. The goal: migrate the platform into a tech-debt free and AI-ready architecture capable of adapt to new use cases and technologies.
Tech Debt Factors
Inconsistent data models in a non relational DB.
Inconsistent data access patterns in a non relational DB.
Inconsistent code structure.
No automated tests.
Business logic present in the frontend.
AI-Ready Architecture
Lack of data engineering (no preprocessing and no collection).
Product Discovery
New user types.
New use cases.
Move Business Logic to a New Backend (Containerized GoLang Service)
> Better business logic management and control.
> Improved consistency in data operations.
> Creation of data access patterns.
Migrate to a Relational DB (Firestore → Postgres)
> SQL available allows changes in use cases to adapt fast and easy.
> Data consistency is key for AI integrations and development.
> Less bugs due to unknown data values.
Build a Recommendation System Using New Data Models
> Use collected data to provide the best match suggestions.
Refactor Code Into Clean Architecture
> Predictable code structures makes them easier to change and adapt.
Improve Dependency Managements
> Dependency management makes automated tests easier to implement.
Write Unit Tests and Integrations Tests for Main Use Cases
> Automated tests prevent regressions.
Team
1 Frontend Developer
1 Backend Developer
2 Extra Support
Process
Iterative - Incremental
Estimated Time
6 Months
Total Execution
7 Months + 1 Month of New Features
1
2
3
4
Proof of Concept
City search service and tour building.
Partial Migration
50% data models migrated (read-only).
Full Read-Only Migration
100% data models migrated (read-only).
Complete Migration
100% data models migrated (read-write).
DB migrations are always hard to go through, especially when migrating from a non-relational DB to a relational one. The team had to design a solution capable of migrating while keeping production live.
Strategy
1. Make new DB read-only and old DB write-only (CQRS). Sync on every write via triggers.
2. Full migration scripts for each data model once the previous step was proven stable.
Over time, the migration was achieved successfully. This two steps approach allowed us to use all the benefits of a query language like SQL, while not disrupting production. Code freezing was not required, enabling changes coming from new requirements and ideas. On top of that, being able to join data in the new db boosted performance by 10x in many of the queries.
