Ticketgum

The main objectives were to:

Migrate and unify the infrastructure of several web portals (Drupal 7, WordPress, custom PHP, and custom tables) to a single Drupal 10 architecture.

Platform Features include:
- ticket sales (Commerce);
- selection of seats in stadiums;
- lots of multi-level categories of tournaments, events, etc.;
- back-offices for administration and affiliates to manage and see reports on user's purchase activities;
- a lot of A/B testing.

Data:
- 190,000+ users;
- 20,000+ events;
- 150,000+ tickets;
- 600,000+ orders;
- hundreds of gigabytes of files.

The ticket reservation system is complex. 
A 15-minute time slot is given to buy a ticket. During this time slot, other users should not be able to book the same ticket. 
For example, 1 sector can have 20 tickets. Then within those 15 minutes users should see another 19 tickets in the sector. But not to see the temporarily reserved 1 ticket.

The platform provides its affiliates with all the needed ticket data via API.

The current Drupal 10 architecture includes:
- a vast number of views;
- a lot of custom code;
- Drupal commerce: cart, cart currency resolver, currency exchanger, Stripe as a payment gateway, domain access, Ajax add to cart;
- the standard checkout flow;
- Layout Builder;
- SVG maps with sectors;
- categorized events;
- FAC search;
- direct checkout by URL.
Upgrade to Drupal 11 is in plans.

The migration complexity was caused by the absence of watermarks on the custom architecture to cling to. As a result migration performance was slow and had to be optimized. There was no migration path since it was migrated from a custom solution to Drupal.
That’s why migrations were self-written instead of native Drupal mechanisms. Custom migration plugins had to be made for all migrations.
The migration included users, orders, blocks, categories (leagues, teams, tournaments), crawlers, aliases, tickets, emails, submissions, files, products, coupons, back-offices, blogs, etc.

A standard Drupal suite on Front-end. 
The Gin theme is working on the admin part, and the entire front end is on Emulsify.

Cloudflare:
- Bot Fight Mode;
- DDoS protection;
- exceptions for specific URLs to firewall rules;

Back-office part is a CMS part for admins and affiliates to manage all the business processes
It is used by sales, marketing, and inventory management departments.
Sales:
- lists of orders;
- management and tracking of an order status;
- the order page with all the information about the user and e-mails;
- SMS;
- the history of changes to the order status.
Marketing: the status of marketing campaigns from CSV reports.
Inventory: flow management and connection of physical tickets with sold ones.
Content and taxonomy management is also done via the Back-office part.

4 previous databases were replaced by the Domain module and its ecosystem:
- domain access; 
- domain config;
- domain config pages;
- domain access entity;
- domain path auto;
- domain redirect;
- domain simple sitemap.
As a result, the previous Back-office, blog, and websites now have a single codebase and database.

SEO
Simple XML sitemap, Metatags, Schema.org

Integrations with:
- Klaviyo (email campaigns); 
- Sandgrid (emails);
- Zendesk (Issue Tickets to handle); 
- TiXstock (we take tickets from them and resell them); 
- Twilio (SMS).

Performance Optimization is mostly handled by Drupal 8+ caching. 
Cache tags and contexts have been correctly placed from the start. 
Frequently updated data is transferred to BigPipe. 
Everything that delays loads is transferred to Ajax, cache warm-ups. 
Heavy operations are executed via Cron.