Wix.com - 5 Event Driven Architecture Pitfalls!

TL;DR

Wix encountered common pitfalls when migrating to an event-driven architecture, including reliable event publishing, overuse of event sourcing, difficulty in visualizing workflow, handling large messages, and managing duplicate events.

Transcript

the company Wix migrated from a request reply RPC style system to an asynchronous event-driven architecture not surprisingly they ran into a few issues thankfully one of their developers wrote a blog post outlining five of the pitfalls I'm going to shed a little bit more light on some of the problems and solutions that they had outlined in this blo... Read More

Key Insights

• 🪛 Reliable event publishing during state changes is a common challenge when migrating to an event-driven architecture. Wix addressed this by implementing their own messaging platform and using a Kafka Source connector.
• 🥺 Overusing event sourcing can lead to complexity, especially in terms of managing snapshots and eventual consistency. Alternative approaches, such as CRUD operations with CDC, should be considered for event communication between service boundaries.
• 🔨 Visualizing workflows and correlating events has become simpler with tools like Open Telemetry and Zipkin, enabling better insights into causation and correlation.
• 🍵 Handling large messages in events can be done through compression, chunking, or referencing an object store using the Claim Check pattern.

Questions & Answers

Q: What were some of the challenges faced by Wix when publishing events during state changes?

Wix encountered issues with reliable event publishing when making state changes in their database, specifically when publishing events to Kafka. They addressed this problem by implementing their own messaging platform called Greyhound and using the Debezium Kafka Source connector.

Q: How did Wix handle the problem of overusing event sourcing?

Wix cautioned against the overuse of event sourcing and emphasized the distinction between using it for state persistence and using it for communication between service boundaries. They recommended considering alternatives like CRUD (Create, Read, Update, Delete) operations with Change Data Capture (CDC) to communicate events.

Q: How can visualizing workflow and event correlation be simplified?

With the advent of tools like Open Telemetry and Zipkin, visualizing workflows and correlating events has become easier. These tools provide visualization capabilities that enable a better understanding of causation and correlation between events.

Q: What are the recommended solutions for handling large messages in events?

Wix suggested three solutions for handling large messages in events. The first is compression within Kafka, the second is chunking the messages, and the third is using the Claim Check pattern, which involves referencing an object store where the actual data resides.

Q: How did Wix address the issue of duplicate events and its impact on inventory management?

Wix highlighted the importance of handling duplicate events, as they can lead to incorrect inventory management. They recommended using versioning or unique message IDs to make event handlers idempotent and ensure the processing of events occurs only once.

Summary & Key Takeaways

• Wix faced challenges in reliably publishing events while making state changes in their database. They implemented a messaging platform called Greyhound and used a Kafka Source connector called Debezium as solutions.

• The company cautioned against the overuse of event sourcing and highlighted the importance of distinguishing between event persistence for state and event communication for service boundaries.

• Visualizing workflows and correlating events can be difficult, but tools like Open Telemetry and Zipkin make it easier to understand causation and correlation.

• Sending large payloads in events can be problematic. Wix suggested using compression, chunking, or referencing an object store through the Claim Check pattern as solutions.

• Handling duplicate events is crucial to avoid issues like incorrect inventory management. Wix recommended using versioning or unique message IDs to make event handlers idempotent.