modernizing ticket marketplace pricing domain architecture
users (in this case, humans who care about the effort): development teams and business stakeholders, with end users being ticket buyers and sellers
the problem: over time, the architecture for a growing ticketing marketplace sprawled and twisted its way into an unmanageable state – base ticket listing prices are calculated, adjusted, and stored in multiple places with no one source of truth. This can impact customer journeys (seeing one price throughout a buy flow and then another a couple clicks later), makes it tricky to enhance the system with dynamic pricing functionality, and ultimately, it negatively impacts business bottom line.
goals:
- reimagine ticketing price architecture using real-life business and customer flows as north star
- facilitate event storming across multiple use cases to establish critical domain candidates
- map out a future state to include single-domain data storage, synchronous API calls along with asynchronous pub/sub messaging for widely-consumed state changes
- enable a development team to think critically about future states without getting too bogged down in the “complexities of now”
- keep future business goals in mind – prioritize the right system domains first to enable new feature development as soon as possible
lessons learned:
- it’s wise to set expectations early on about how much physical space and time a new project’s kickoff will require
- experiment with meeting facilitators early to identify who might need leveling up vs. who can be a strong leader when needed
- it’s ok not to get too hung up about certain stakeholder’s lack of involvement and press on anyway
- define key OKR’s for shorter engagements focused on planning, continuously call out the differences between goals for a plan vs. executing the plan
