You've probably heard of Wix.com, but did you know they're a Kafka shop? They are, and they use it, as we say, at scale. I talked to Wix backend infrastructure engineer Natan Silnitsky about how he serves 900 developers maintaining 1,500 microservices and what lessons the organization has learned. All on today's episode of Streaming Audio, a podcast about Kafka, Confluent, and the Cloud.
Hello, and welcome to another episode of Streaming Audio. I am, as ever, your host Tim Berglund, and I'm joined in the studio today by Natan Silnitsky of Wix. Natan, welcome to the show.
Hi, Tim. Thank you so much for having me.
You bet. First of all, I'm going to assume Wix is a company that needs no introduction. It's a website builder. It's Wix.com. If you don't know what it is, go look at it. I am personally not a Wix user, but I can say I am married to a Wix user, so this is a thing that gets spoken of in my own house. So, exciting for me to have you on.
Natan, you're, by your own description, a backend infrastructure developer at Wix, but tell us a little bit about what you do and how you came into the job. What did you do before this, and how did it lead to what you do.
Sure. So I started off at Wix working on Wix payments solutions, so how those site visitors pay those site owners' stores or restaurants, stuff like that. There were a lot of challenges to do basically the payment infrastructure for all the different verticals at Wix. But then I got an offer to work on migrating our build system for all the backend to Google's Bazel build tool, and I jumped on it. I thought, "Okay, so that's going to be very different from what I do day-to-day." Focus on infrastructure, helping developers instead of thinking about the product.
And it was a really great experience, and once that migration was over, I thought, "Wow, I really like developing infrastructure, thinking about writing libraries and tools to help developers achieve their goals. It's very interesting, and also you get exposed to a lot of new, fascinating technologies."
And once I heard that there was an opening to work on the data streams team at Wix, which was a relatively newly formed team dedicated solely to Kafka and data streaming, I jumped on it because I thought, "Wow, this is great." About event-driven style of development. It's cutting edge, working on a lot of different areas, basically, because we have expanded, but more about that later on.
But we're working on libraries, working on production tools, interacting with our developers, making sure they have a good experience when they work with event-driven style with message passing, with streaming of data.
So, I was really excited to join the team, and I've been there for a year and a half now.
Cool. In the backend infrastructure role?
Yeah. Specifically for Kafka-related area.
Oh, wow. Okay. Cool. So that puts you in the top few sigmas of Kafka users in the world, probably, just in terms of direct exposure. And scale, really, Wix is not a small-scale company.
The question I'm about to ask, I'm aware, is rather broad. But how does Wix use Kafka? Where does it fix into the stack, to the extent that you want to and can describe the architecture? Lay that on us and tell us where Kafka fits in.
Yeah, sure. I know that Kafka is used tremendously by a lot of big data companies. It's the entire pipeline of processing it with ETL and all of those buzzwords on big data processing. At Wix, there is a different sort of scale here. We use it for message passing between all our different micro-services, and we have a lot of them. We have roughly 1,400 micro-services communicating. And while some of the communicating is done via gRPC, I will say it's 50/50 now is going through events and then Kafka. So, we produce over a billion messages every day in the system. It's a big scale data, so it keeps growing for sure.
So there a lot of services working with it, a lot of developers. We have around 300 backend developers and a lot of front-end developers as well, which run Node.js middleware, also use Kafka for their services. A lot of developers that we need to support on our team. So, the scale here is huge but not necessarily trillions upon trillions of messages every day, but a lot of different use cases, a lot of different needs for our various products out there.
You said some services still talking over gRPC. I appreciate you being willing to confess that in public. I think that we can still be friends. Kidding aside, is the direction from synchronous to asynchronous? Is that the desired next state?
Yeah. Definitely. The way I see it when you deploy a service globally, it's found in multiple data centers and points of reference around the world. And then you have the service calls, the service calls, the service calls, the service. And you expect to get the results then and there. You end up with cascading failures and a lot of issues where... You have a brittle system, the way I see it, and the more you use a message broker, you'll have better fall tolerance. You'll be able to decouple these services from one another.
I really like the series of blog posts by Consulate on how Consulate sees the data, data unbundled, or something like that. Where you take the database, the traditional database, and you change it conceptually completely, and each service can consume its own streamed, materialized view of what it needs. And in an event-driven manner, where it's less dependent on other areas of the system, so it's a much more resilient and, I would say, more decoupled and easier to reason about in each small granular component of it, and that's the recommended way. So, of course, gRPC is not going to completely vanish, but I see the benefits are clear to most of our developers, and we witness it by the growth of the usage. It's phenomenal.
I just loved every word of that. I say those words. There were certain key phrases you use that I say a lot, and every time I say them I'm aware that I'm playing that record again. And I always wonder, do people get tired of hearing me say that? Does it feel like a cliché at this point? And then when you come here and say that, you're like, "No, really, we're a billion messages, 1,400 micro-services. I run this thing, and these are architectural outcomes." It's just nice to hear. So, thank you.
Don't let me... We're here to talk about infrastructure. We're not here to talk about the broader architectural implications of all this. Maybe that's a future episode because it sounds like you've got good things to say about that as well. But seriously, good stuff. If we did, some podcasts open with a little cold open of a quote from the thing, something from what you just said would have been that cold open, because that was gold.
Cool, and sometimes a cliché becomes the mainstay of the industry, so I think that's a good way forward.
Yeah, where it's actually true. That's why it gets said all the time.
But scaling like this. Wix, obviously a large global company. One would probably call it web-scale, if we could use that term without irony. And certainly a large Kafka installation. You've given a talk about lessons learned in using Kafka at Wix, and I've got a list of those here. And I'd like to just talk through some of them, especially from your infrastructure perspective, where you are providing infrastructure tools to application developers. And I heard you say Node. Are there other languages in the stack that you need to take care of?
Yeah, definitely. So I would love to talk about these lessons. I would say the main stack is JVM Scala based, but Node.js is growing.
Nice. Okay. So I've got a list of these here from your talk, and I'm just going to go through as many of them as we have time for. So number one, your first lesson was that I think you found it desirable to build common infrastructure, by which I think you mean something like a client wrapper. Is that right?
Yeah, so it was apparent from the very beginning that we use the Kafka SDK as is, but as a growing company... We started using Kafka in 2015, and already then there were quite a few services. I'm not sure. I think it was already called micro services back then. And from the beginning, it was clear that we can have each service do its own thing with Kafka, but there are broad features that can be put into all the services, especially if you want to have a coherent way of messaging between them.
How many application developers would you be serving with that layer?
Today, we have around 300 backend developers and a few hundred more front-end developers with Node JS. So I would say 500, 600.
Got it. And I just want to say, it's very typical at this scale for organizations to do what you're doing. Some people have discomfort with this, wrapping the clients. And honestly, Natan, I'm one of them. I always feel like your wrapper is going to be too opinionated. You're not going to be able to maintain it enough. New features aren't going to get exposed to your application developers in time. And blah blah blah, all the reasons you don't want to do it. And I feel those.
But it's interesting that basically 100% of organizations who have on the order of 10 to the two developers using Kafka, as you guys have, 100% of them seem to create a wrapper like this to solve all the problems that you just mentioned. And expose features that are Wix-specific, in your case, to your internal developer community. Everybody does this, and it seems like it's the right thing to do.
You may have had more to say. I interrupted you there. I couldn't help it.
It's great. You mentioned there's a new feature coming, Kafka SDK, but think about the need to upgrade the versions. So, you want to have that taken care of for you. If there's maybe breaking API potentially or stuff like that, you really want to have more control of it when you hundreds upon hundreds of developers that rely on it. And they really want it to have it just work, right? Even on upgrades. They don't want to mess around with it too much, so there's that as well.
You mentioned that it's also nice to have extra features. For instance, our client wrapper, it's called Greyhound, by the way. It will inject automatically the broker locations, so the user does not need to worry about that. And it does the message commit for our users.
We, from the very beginning, thought that having at least once processing is the way to go instead of at most once because like I said before, it's not the big data like sensors data. It's really Wix user requests, incoming user requests now. You want to handle them without missing any messages.
So, Greyhound handles the commit for our developers, which just specify the processing code and the lambda, basically. It also handles the message [inaudible 00:15:47] in case maybe they have a lot of code there that's kind of slow and messages keep building up, message queuing keeps building up. So, it will stop requesting, pulling more messages from Kafka, stuff like that.
And also parallel message handling. So, we want to utilize our CPUs as much as possible. We don't want them to be like 20% idle. We're paying our cloud providers for these CPU units, for these core units, so want to have as much utilization as possible with as little amount on instances as we need.
So, in Greyhound, you get parallel processing out of the box. You can scale it to be more. Of course, it's limited to the amount of the partitions that the Kafka topic has, of course. But other than that, you can get a very high degree of parallelism, and with Scala, it's really easy to do, actually implement that.
It's funny you say that. I was about to stop and provide a content warning to the audience. I was going to say, "Ladies and Gentlemen, we have a Scala developer talking about using multiple cores. I can't be responsible for what gets said next."
But no, you're right. This is a thing that a Scala team is going to be thinking about this. A good Scala team is going to deliver on this. It's just going to happen.
I mean, Scala has it's issued. It has a very rich set of styles, so what happens is that your code becomes a bit unreadable at parts for some developers. But almost all developers will share the immutability and the ability to provide concurrency in a safe manner, and that's what we do on our client wrapper, Greyhound, for Kafka.
Another critical feature which I talked about, the need to never lose messages, never lose processing, at least most processing, is to retry processing upon errors both for the consumer side and producer side. We support a few flavors for that. That's a critical use case for us for Kafka in general.
You can create a gRPC request and maybe even retry local a few times, but you don't have the Kafka message worker that has the message, and you know it's not going to go away, and you can safely retry... In offline jobs, maybe you can even retry after an hour and still succeed. It's just a wonderful, important feature for a serial system that needs to work flawlessly, eventually.
Having built this sort of layer, this client wrapper... Oh, wait, no. I almost forgot the question. Do you guys, being partially a JVM shop, is there any Kafka Streams involved in the clients at all?
Good question. So, we start off in 2015, and at that point, I think Kafka Streams maybe already was out in the open, was really just starting. So, they were still used producers and consumers slowly. There are separate units at Wix that are not part of the main bulk part of the product services that utilize Kafka Streams. It's mostly also in the business intelligence unit and the data organization part, but not on the microservices product-oriented part of Wix.
Got it. How about any KSQL? We didn't talk about this at all, so this is just a random curiosity on my part.
Okay, so you say that there is a lot of common use case for ksql without Kafka Streams? I wonder.
No, it tends to be a trade-off where like a Java shop, everybody's got to commit to Java. It's typical for those Java developers to learn Kafka Streams and use it. And then when presented with KSQL, they'll usually say, "Well, we learned Streams. We're okay. We can get this done with Streams," because they've made the investment, and they want to continue to have that investment pay off.
A lot of the things that you can do with Streams, you can do with KSQL, and so in non-JVM shops, like you said there were lots of Node.js, KSQL tends to pop up for stream processing in those use cases or those contexts more.
So, we haven't utilized KSQL on our side. I'm not sure about the other parts of our organization. Wix is a big one. I think they're more Kafka Streams oriented than KSQL.
Now, having built a robust client wrapper that does all those things, and having literally hundreds of developers who are using it, that is an internal product development effort. You don't know all those people. You're not communicating with, any sort of reciprocal way, all of the people who use the wrapper, which brings up internal tooling, internal documentation, and things like that for your wrapper, and those aspects of productizing Greyhound.
I should start calling it Greyhound since that's what you guys call it. So, tell me about tooling and docs around this.
Sure. So, like you said, we have this whole additional layer infrastructure, and while I earlier praised the event-driven style of development, you do need to have the tools in place to debug production in an easy manner. Because with gRPC requests, it fails, you get the failure. But here, if you produce a message, you need to somehow understand...
That's the end of your job. Then you have the consumer side that needs to make sure that the processing is done correctly. And when you have it end to end, sometimes it gets a bit tricky to understand what's going on. So, you definitely need to have the tool in place and the education, basically, of your developer corps, I would say.
And we only like a small infrastructure around Kafka and a lot of product developers. So, we decided to create self-service tools. The most important one is we created our own control plane user interface. There are, of course, other tools out there. There's the famous Kafka CLI with Kafka Console Consumer, et cetera But we thought that a graphical user interface will help out our developers use it easily and not get into the details of different flags that you need to support in the CLI, including broker location and [inaudible 00:23:41] location.
And there are graphical user interface control planes out there, both open source and commercial. I know that Confluent has one, right?
But because of our unique infrastructure layer, we decided to create our own tool, and we called it Greyhound Admin. So, we have all kinds of features there, some typical, like configuration of topics, straining the messages, debugging messages for a topic.
But interestingly, one of the key issues with debugging Kafka production is lag monitoring. The producer produces the messages at some rate, and the consumer is not really dealing with it in a speedy manner, and the lag is built up between the producer and the consumer, and you want to investigate it. You want to know, wait a minute. Is it one partition that is lagging now, or is it all the partitions?
And so, we built a nice feature on this control plane user interface where you can check out, okay, this topic. Who consumes it? Oh, nice. Okay. Oh, here I see my consumer group. Okay, let's look at the partitions and see... Oh, wait a minute. It's only one partition that is stuck, so let me now switch over and stream messages for this partition and understand why is this partition has this lag.
We also have monitoring [inaudible 00:25:40] in place to see if handlers are stuck for each application. And this way, it's really, in a few clicks, the developer can basically understand what's going on. I hope I put the example in a coherent manner.
Can you tell me, Natan, how many topics you guys have, approximately? Is that a thing that you're allowed to say?
Sure. I think... Let me refresh my memory. I'm not sure the order of magnitude for some reason, but I think it's either something like 5,000 or 50,000.
It's always the exponent. [crosstalk 00:26:27]
You know the mantissa, but those pesky exponents.
I probably remember it's something like 5,000 topics and 50,000 partitions approximately.
There you go. That sounds reasonable. That's big, and that introduces... With 1,400 services and, we'll say, 600 developers, that introduces the question of schema management and schema discovery. So, just basically, how do you handle that? Does Greyhound participate in that? How you do that from a tooling and documentation perspective?
It's a very important topic because you don't want your developer to go and ask each team, "Hey, how are you doing? What's your message schema?" And stuff like that. It's really non-scalable in a larger organization.
Because we use gRPC, our message schemas are in protobuf. Across all of Wix, everything is protobuf, and so Kafka messages are in protobuf format. And basically, each service has a swagger output that provides for the message details, what are the events, and what do they have. And then, it's the job of each developer that wants to consume it to go to a site that we have... Everything on Wix is a site, so they go to a site, and they can see all of the different services and all of the events, messages that they produce. So, the developer can consume it and see exactly how to consume it.
But we don't have a very good versioning story. There's a basic protobuf compatibility that you can have. If you have a new version, it's always difficult to get the developers to switch to the new version and stuff like that. It doesn't happen a lot, but when it happens, it will probably be a very manual process.
So, I heard about the schema registry that Kafka has, right?
Yes, that's a Confluent schema registry. It's not a part of Apache Kafka, but it's free to use source available thing.
I understand that the versioning there is quite good, versioning management.
There's kind of two things, as I see the value to schema registry. One is it encourages you to use what amounts to an interface description language, a file to describe your schema. And then, tooling to derive the actual objects, to generate source to define the objects in the language of your choice.
That's similar to protobuf.
So, you've got... Right, you can do it with protobuf. You can do it with Avro. The other thing is migration when you are evolving schemas. It doesn't automate that, by any stretch of the imagination. Migrating schemas is kind of always a terrible thing to do. But when you've got lots of consumers and producers who are potentially uncoordinated and don't communicate well... Human beings don't communicate well, not that that would ever happen ever, but imagine. Use your imagination. It will help make runtime assertions and build time assertions that producing that message will fail, or consuming that message will be a problem, based on your compatibility rules.
However, it was like three months ago, as of the time of this recording, that the schema registry started supporting protobuf. Don't feel bad for missing the boat. That's a thing you guys could look into now. It's an option, but literally half a year ago, it was not an option for you as a protobuf shop.
Oh, that's good to know.
It's a good future thing, and it is not a boat you have necessarily been missing, given your other commitments.
Is Greyhound a thing, publicly? Is it open source?
Yeah, I forgot to mention that Greyhound is open source. We open sourced it a few months ago, and it has all of the features I mentioned. Of course, we have an additional Wix layer on top of it that is private, in a private repository. But all the features I mentioned and more are found in the open source version, and you can go and check it out on GitHub. It's on the Wix organization, just called Greyhound. So, GitHub.com/Wix/Greyhound.
Awesome. I could be persuaded to put that into the show notes.
And you mentioned you document these things internally with sites. How do you build this? All those sites?
That's an entire show on its own, I guess.
Exactly. The short answer is dogfooding, and that's a good thing. Wow, you can do cool stuff, too. If one team wanted to charge for access to premium documentation, you've got all the eCommerce stuff baked in already. You can just do that.
That's a good idea. You should be on our business development team.
Little hustle on the side.
We do a lot of dogfooding. A lot of our back office tooling is done using the Wix platform. Actually the Greyhound control plane, we didn't use the Wix platform itself, but we did use Wix open source called Wix-style-react that allowed users to write React and don't even think about CSS and styling at all because you get it out of the box. That was nice.
Nice, yeah. You had me at don't think about CSS.
Yeah, I hate CSS.
There are people who don't, and they are a gift to human flourishing, that they love CSS and are good at it. The rest of us need them and should encourage them and send them a fruit basket during the holidays is what I think.
How about another lesson that you've got. You talk about it in your talk. It's about monitoring, and this is a thing that comes up.
Monitoring, you're architecture doesn't matter. If you've got a monolith, if you've got synchronous microservices, if every single thing in the universe is asynchronous and reactive, like it should be, monitoring is still a problem.
But it feels like a bigger problem with an asynchronous system because at the point that you have some request that you been made aware of from the outside world, and you validate that request and do some computation around it, and then you produce that unit of work to some topic that you know 15 other services are going to dance around until the saga is complete, or however you want to put it... Monitoring feels like a bigger problem because the code that you write to process that user request does not have direct responsibility for completing the action, and you're just trusting all these services to be adults and fulfill their responsibilities.
So, tell me about monitoring and whether that's part of the Greyhound story or other stuff you've built.
It's half and half. Dev culture at Wix is you have complete ownership of your service, including monitoring it. But of course, there are teams to support you. There's the data stream team that I'm part of, and there's a monitoring team.
So, what we do with Kafka related monitoring is that there's an automatic dashboard for each service that is provided in terms of a Kafka related matrix, and it includes a lot stuff you'd expect, like produced throughput, consumer throughput, and stuff like that. But also something that can be monitored and metered because of our Greyhound wrapper layer is [inaudible 00:35:59] current handler.
What do I mean by that? The developer provided Greyhound with the processing code so Greyhound can measure how long it took. It can also offer a gauge to see how long is it taking right now when you actually look at the graph. And then you can say, "Okay, I see a lag is building up because I got an automatic alert on our system for incoming lags." And now I can check out this automatic dashboard and see whether I have a stuck handler. Then I can go and open that specific application. I can see the message that is currently being consumed and decide what to do with it.
So, you need to think about it end to end, and you need to think about the developer. When they run into an alert, do they have the tools in place to actually fix it? It's very important. You get the dashboards. You get the alerts. And everything has to be simple and out of the box, otherwise, you can't really make sure that all 1,400 microservices have the monitoring story as well as they should.
And of course, on top of all that, we have the control plane, where they can continue debugging and view a lot of different aspects as well.
Great point, and I think a broader architectural principle there for organizations of your scale. It's not just that you can't trust application developers to be competent. That's not the framing that you want. Which is typically... I was always on the application side of things, and the infra and app dichotomy, sometimes toxic narratives build up there where people who get beeped and paged in the middle of the night and are responsible for uptime just think that the people who write application code are all completely stupid and make mistakes all the time.
You don't want that kind of thing, and I like the way you have framed this. You can count on them.
Well, at Wix, actually, the application owner will get up at 3 AM if their application is burning.
Oh, nice. That's dev-ops where it counts. Or, as we say, skin in the game. But at your scale, you're just not going to be able to expect that community of hundreds of application developers to also assume responsibility for those infrastructure concerns. Those are actually cross-cutting framework things, and part of what you've done is build that framework.
As the infrastructure team, that's you're a problem to solve. You've solved it. You've given this tool to those people, rather than saying, "Oh, yeah. You have to do this other super complex job that is a calling all in itself and a career specialty all in itself in addition to understanding how restaurants operate and what they need in their front end." All the stuff that the front end people need to care about.
I like that. That's a good way to handle monitoring responsibilities, and just cross-cutting concerns generally. Extract them into a framework. At this scale, it's worth the investment. And then support that framework, which is what Greyhound is all about if I am hearing you correctly.
Yeah, it's a nice way of putting it.
Let's see, we're coming up against time, and I'm thinking maybe we have one more thing. I want to let you pick. You've got a list here. What's you're next lesson you'd like to talk about?
Well, I think I'll be greedy, and I hope we have time for two more lessons.
All right. Let's go.
One of them is that we talked about being a Scala shop and also a Node.js shop. So, the JVM, we have the great Kafka SDK, and for Node.js we used to work with... I think the library's called No Kafka or Yes Kafka, something like that. I know it wasn't officially supported by Confluent or Kafka Open Source Project. It had its own problems, a specific library for edge cases.
So, that was the situation. We have the Greyhound in Scala services, and we have this other library for Node with a little extra infrastructure work by our Node platform developers. And we saw that this is not great because Node services should be first-class citizens and enjoy all the event-driven reactive style development with all the features that Greyhound offers.
But porting all the code from Scala to Node.js doesn't really make sense, so we decided to create a sidecar inside the [inaudible 00:41:36] pod where the Node service runs. It just takes Greyhound as a service, basically, in a sidecar. It's a proxy, basically, where all the produce and consume is done via gRPC calls back and forth between the two containers in the pods.
So, not only does the sidecar need to be a server that gets produce requests, but also the Node app is a server that gets the consumer requests. And we decided to do that and not use some commercial provided [crosstalk 00:42:25] proxy.
The Blizzard Node.js library or any of the... There are a couple of other options that Node shops tend to use. So, in other words, you are not directly using a Kafka library in your Node clients, but you've got this sidecar. And you know what, Natan, I'm going to say, if there has to be asynchronous interface, if it's two containers in a pod, I'll allow it. That seems okay to me. And then, it's the sidecar that is using your... That's Greyhound, then, basically.
Yeah, it just uses Greyhound and the Kafka JVM SDK.
Oh, yeah, sure, because it's not just that, okay, there are Node.js libraries. Go bite the bullet and use the Blizzard one because everybody else does. But it's Greyhound, and you have to port all of Greyhound to wrap that in Node. Okay, that makes sense. Cool.
But I'll go check out the Blizzard one. My curiosity's piqued.
Totally, do. I mention this because this has come up. Somebody asked me on Twitter recently, "Hey Confluent, when are you guys going to have a formally supported Node.js library?" There's noise about that and, I think, growing community desire for a quote-unquote "official" one.
The Blizzard one is the de facto official community library, just based on people I talk to. That's a thing, but that still wouldn't solve your Greyhound problem. You've got all this value wrapped around the JVM.
Anyway, you said you wanted two, and the way we get to two is by me talking less. So, talk to me about proactive broker maintenance and lessons you learned there.
We currently maintain our own Kafka brokers, of course, on the Cloud, but by ourselves. In terms of lessons learned here, it's really important to monitor the growth of your clusters. Wix is quite a big shop, and there's a famous blog post about the optimal amount of partitions and brokers in a cluster.
I know that once the ZooKeeper KIP will be fully blended, we'll have a lot more threshold, but I think it's currently something like 4,000 partitions per broker and 200,000 partitions per cluster. Correct me if I'm wrong.
That would be prior to, I think, Kafka 2.0.
More up to date versions of Kafka within the last year or Confluent platform, you'd be around 20,000 partitions per broker. And mileage varies on that. I'm saying that number, and the operator might say, "Nope. Sorry, we tested it, and it was 12,000." And that's all totally cool. [crosstalk 00:45:33]
You would agree that ZooKeeper is a bottleneck here.
I would agree, Natan, that ZooKeeper is a bottleneck. This is why we have a KIP 500 and why we're excited about the future, but go on.
I'm also excited about that. The main lesson here is to be proactive, and add additional brokers, and delete unused topics, and if you need to split up your cluster because it reached the limit, then go ahead and do that.
Actually, we are now considering switching over to Confluent Cloud. That will...
So, that will hopefully release us from the need to do the broker maintenance because like I said, as our scaling requirements keep growing, you need to be on the nose and keep maintaining and checking that everything is okay. So, if someone else can do that for us, why not? That would be great.
But basically, we also want to split up the cluster. We have one big giant cluster now for each of our data centers, and it's reached the limits, I think, even if we probably move to Confluent Cloud. It's still something that we want to do. Then we have all the concerns of how to split the clusters and make sure that it's easy on the Greyhound API level to use it, maybe without even going to the API level, having it behind the scenes to go between clusters, et cetera.
So, it's going to be an interesting time for us.
My guest today has been Natan Silnitsky. Natan, thanks for being a part of Streaming Audio.
Thank you so much, Tim. I really enjoyed the conversation, and I hope that some of the lessons I described will help any of our listeners.
Hey, you know what you get for listening to the end? Some free Confluent Cloud. Use the promo code 60PDCAST to get an additional $60 of free Confluent Cloud usage. Be sure to activate it by December 21st, 2021, and use it within 90 days after activation. And any unused promo value on the expiration date will be forfeit, and there are a limited number of codes available, so don't miss out.
Anyway, as always, I hope this podcast was helpful to you. If you want to discuss it or ask a question, you can always reach out to me @tlberglund on Twitter. That's T-L-B-E-R-G-L-U-N-D. Or, you can leave a comment on a YouTube video or reach out in our community Slack.
There's a Slack sign up link in the show notes if you'd like to join. And while you're at it, please subscribe to our YouTube channel and to this podcast wherever fine podcasts are sold. And it you subscribe through Apple Podcasts, be sure to leave us a review there. That helps other people discover us, which we think is a good thing.
Thanks for your support, and we'll see you next time.
Did you know that a team of 900 developers at Wix is using Apache Kafka® to maintain 1,500 microservices? Tim Berglund sits down with Natan Silnitsky (Backend Infrastructure Engineer, Wix) to talk all about how Wix benefits from using an event streaming platform.
Wix (the website that’s made for building websites) is designing a platform that gives people the freedom to create, manage, and develop their web presence exactly the way they want as they look to move from synchronous to asynchronous messaging.
In this episode, Natan and Tim talk through some of the vital lessons learned at Wix through their use of Kafka, including common infrastructure, at-least-once processing, message queuing, and monitoring. Finally, Natan gives Tim a brief overview of the open source project Greyhound and how it's being used at Wix.
If there's something you want to know about Apache Kafka, Confluent or event streaming, please send us an email with your question and we'll hope to answer it on the next episode of Ask Confluent.Email Us