Case studiesTicketing and events

Ingresse: diagnosing and modernizing ticketing workflows

Peak ticketing periods exposed failures in a legacy platform that were hard to diagnose. During a 2022 consulting engagement, Paulo Cardoso mapped Ingresse’s purchase workflow, added operational visibility and helped modernize critical services.

Business
Ingresse
Sector
Ticketing and events
Scope
Observability and staged modernization
Contributor
Paulo Cardoso
Editorial illustration: a metal ticket mechanism feeding a blank orange ticket strip
AI-generated editorial illustration of the project’s domain.

Revenue depended on queues and workers the team could not observe.

The legacy PHP platform had accumulated background workers and queues without enough metrics to explain their behavior. When a worker failed or fell behind, the business saw a disrupted purchase or ticket flow before the team understood the cause.

Ticketing demand arrived in spikes. The engineering task was to identify the actual bottlenecks and improve the critical path while the platform continued supporting events.

Map and measure the workflow before choosing what to replace.

Paulo did not begin by changing code. He first mapped how the services communicated, where purchase and ticket flows passed, and what each queue and worker did. Then he used New Relic to put metrics on the worker layer for the first time.

With traces and queue metrics, the guessing stopped. Bottlenecks became visible. Some workers were optimized. Others were cheaper and safer to rewrite. Unnecessary database queries appeared in the traces and were removed.

What the workflow includes

  • Map communication between purchase and ticket services.
  • Instrument queues and workers with New Relic.
  • Move payment, order and ticket processing to Node.js and TypeScript on AWS.
  • Connect new services through an API gateway and stage lower-traffic cutovers.

A phased migration with a clearer view of the purchase process.

The work made queue and worker behavior visible, allowing the team to identify database and processing bottlenecks. Payment, order and ticket services moved through a phased migration that connected the legacy platform to the replacement services.

What this means for the technology owner.

A takeover starts with understanding the existing system. Observability can reveal where a small optimization is enough and where replacement is justified. The lasting handover includes the service map, measurements and reasons for each change, so the next team can make decisions from evidence.

Taking over existing business software →

PHPNode.jsTypeScriptAWSNew RelicAPI Gateway

Project contribution: Paulo Cardoso. The scope described above identifies the work behind this case.

Editorial review: Ego Eimi · Updated September 6, 2026 · About the team

Your technology

Start with the business

Your business depends on it.

Tell us which system matters, what has changed and who controls it. We will define a reviewable next step. Read Foundation and the commitments and evidence.