Leveraging services in stream processor apps at Ticketmaster (Derek Cline, Ticketmaster) Kafka Summit SF 2019
Is your organization adopting Kafka as their messaging bus but you've found that it will take too long to migrate your existing service-oriented architecture to a log-oriented architecture? Some of the biggest challenges in building a new stream processor can be implementing all the business logic again. It has become increasingly common for companies with high-throughput source streams and change-data-capture logs to want to build systems fast. At Ticketmaster, we have found a solution to the problem by leveraging the business logic in our existing services and calling them from our Java based KafkaStreams processor applications in an efficient manner. In this talk, we will examine the initial challenges we faced in our transition, then we will explore the solutions we built to address the use cases at Ticketmaster. The primary focus will address our workflow around calling services to bring stream processor applications to market fast. We will review our challenges and share tips for success.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Leveraging services in stream processor apps at Ticketmaster (Derek Cline, Ticketmaster) Kafka Summit SF 2019
Similar to Leveraging services in stream processor apps at Ticketmaster (Derek Cline, Ticketmaster) Kafka Summit SF 2019 (20)
More from confluent
More from confluent (20)
Recently uploaded
Recently uploaded (20)
Leveraging services in stream processor apps at Ticketmaster (Derek Cline, Ticketmaster) Kafka Summit SF 2019
- 1. Leveraging services in stream processor apps September 2019 Derek Cline @derek_cli
- 3. Ticketmaster History 3 LOOKING BACK • Ticketmaster started by two ASU college staffers and a business partner in their garage in Tempe ‘76 ‘77 • First ticketed show was Electric Light Orchestra at a venue in New Mexico ‘96 • First-ever Internet ticket sale (Seattle Mariners) ‘07 • Invests in service oriented architecture ‘15 • Started Kafka Streams, event driven architecture, journey ‘19 • Heavy Kafka Streams adoption throughout the organization
- 4. Discovery 4 LOOKING BACK Search or navigate to find your favorite shows
- 5. Event Details Page 5 LOOKING BACK Everything you need to secure your tickets • Ticket Types • Seat Availability
- 6. Event Details Page 6 LOOKING BACK Pick your own seats on the Seat Map
- 8. Old School SOA Architecture 8 SOA TO STREAMS Pros • Loose coupling • Flexible • Scalable (to a point) • Easy to debug (sometimes) Cons • Scalability can be limited • Eventually consistent (cache TTLs)
- 9. The “Onsale” 9 SOA TO STREAMS • Unique traffic pattern • High demand • Thundering herd • Systems always scaled up
- 10. New School Event Driven Architecture 10 SOA TO STREAMS Pros • Loose coupling • Flexible • Scalable • Easy to debug • Durable • High concurrency Cons • Eventually consistent
- 11. Warning: Thar Be Dragons! 11 SOA TO STREAMS • This use-case doesn’t work for every stream processor application • Works best when… • Source stream throughput is low • Dependent service is: • Reliable • Has low-latency • Has useful error codes Credit:MapfromHyborianAge
- 12. Current Design 12 SOA TO STREAMS
- 13. TicketType Stream Processor Logic Flow 13 SOA TO STREAMS
- 14. Okay, but is it testable?
- 15. Functional Test Framework 15 TESTING Dependencies • Java Cucumber • WireMock • Confluent Platform Tools • Docker • Gitlab CI
- 16. Testing the Burst Reducer 16 TESTING Feature: Combine multiple messages over a 2-second time window Scenario: Multiple messages within the time window, for the same eventId, should be combined into one When 3 messages are produced on the Input Topic, for the same eventId Then 1 message should appear on the Output Topic
- 17. Yeah, but can you monitor it?
- 18. The logs tell the story LOGGING & MONITORING 18
- 19. Bro, do you even monitor? LOGGING & MONITORING 19
- 20. Critical Stream Processor Metrics CHALLENGES 20 •Topic consume rate •Topic growth rate •Consumer lag •End to end latency
- 21. The Burst Reducing Processor in Action LOGGING & MONITORING 21
- 22. What’s Our Objective? LOGGING & MONITORING 22
- 23. Sounds easy; were there challenges?
- 24. What happens when the service you call behaves unexpectedly? CHALLENGES 24
- 25. Ticket Type Stream Processor – Current State CHALLENGES 25
- 26. Ticket Type Stream Processor – Better State CHALLENGES 26
- 27. Stream Processors – Best State! CHALLENGES 27 •Pure Streams! •Get as much data into the source streams as possible! •Implement business logic •Test •Code Review •Deploy •Monitor
- 28. Start Building Stream Processors Now! TAKEAWAY 28 •Don’t wait •Be creative •Identify & leverage overused services •Build out your log oriented architecture
- 29. Thank you! Derek Cline @derek_cli