Unlike with UI frameworks, or software industry buzzwords, data storage technologies, i.e. databases are famously slow to change, and new innovation takes longer to be adopted.
For a large organization, switching to a different OLTP database as your main workhorse happens very rarely. In recent years, with the advent of microservices, more flexibility is given for each service to choose the way it persists it’s data. Still, the risk of using unproven technology sometimes outweighs the benefits, as losing crucial business related data is unacceptable. …
Fibers are the backbone of the highly performant, asynchronous and concurrent abilities of ZIO. They are lightweight “green threads” implemented by the ZIO runtime system.
IO[E, A] effect means it will immediately run on a new fiber.
The ZIO documentation recommends that non-advanced programmers avoid fibers and instead use concurrent primitives like
foreachPar, and so forth, which is sound advice.
But very soon in a lot of different applications, there comes a need to fork a new fiber. The best example would be — running some recurring job.
Fiber management edge cases
When managing the application’s fibers…
Wix’s distributed system of 2000 clustered microservices is required to process billions of business events every day with very high speed in a highly concurrent fashion.
There is a need to balance the load between the various cluster nodes, such that no bottlenecks are created. For serving HTTP requests, this can be done by load balancers such as NGINX or Amazon’s ELB — this is out of scope for this article.
A service acting as a client may also require to load-balance its calls in certain cases. …
Wix has a huge scale of traffic. more than 500 billion HTTP requests and more than 1.5 billion Kafka business events per day.
Caching the responses and events is critical for having the best performance and resilience for Wix’s 1500 microservices.
As traffic to your service grows, customers can face much longer loading and response times, and not return to your service. Network costs can increase and the unexpected load on your DBs can potentially cause them to fail. One of the ways you can mitigate these issues is to introduce a cache.
A cache will reduce latency, by avoiding…
Recently I have learned a lot about what qualities make for a user friendly (and non-user friendly) client library.
Over the last 1.5 years I have been part of a team at Wix that’s developing event-driven data streaming infra on top of the Kafka message broker. The most important part of this infra is a JVM-based client library called Greyhound, which has been in continuous development for the past 5 years and was recently re-written from scratch and open-sourced.
Following are 5 tips for writing great libraries, touching on design, implementation and APIs.
Kafka consumers and producers are used as the event-driven messaging backbone between Wix’s various microservices — 1500 in total. With such large scale, many different requirements were needed to be addressed and great tools provided for many different teams.
We talked about Greyhound, Wix’s own Kafka client wrapper library that has very useful features like easy to setup retry policies and trivial configuration of how much parallel work each client should handle.
Back In January 2020, I wrote two posts (I, II) about pitfalls to avoid when starting to work with ZIO.
9 months have passed. In the interim period, ZIO 1.0 was released and ZIO Environment has been tremendously improved with the introduction of ZLayer.
From my experience it is a real joy to write code with ZIO, especially in cases where you have complex concurrent/async requirements which are much simpler to implement with the features this library provides.
Since January, I’ve written a lot more code with ZIO and had a few more mistakes I’ve made and corrected along the…
As promised, this is the second part of a two part series on key patterns of event-driven messaging designs that have been implemented at Wix and that have facilitated creating a robust distributed system that can easily handle increasing traffic and storage needs by more than 1400 microservices.
I recommend reading part 1 first, where I write about ‘consume and project’, ‘event-driven end to end’, and ‘in memory Key-Value stores’. Here are the next 3 patterns:
…when you need to make sure scheduled events are eventually processed
There are many cases where Wix microservices are required to execute jobs according…
For the past year, I’ve been part of the data-streams team that is in charge of Wix’s event-driven messaging infrastructure (on top of Kafka). This infrastructure is used by more than 1400 microservices.
During this period I’ve implemented or have witnessed implementations of several key patterns of event-driven messaging designs that have facilitated creating a robust distributed system that can easily handle increasing traffic and storage needs. 3 of these are in this post and another 3 are in part 2.
…for those very popular services that become a bottleneck
This pattern can help when you have a bottleneck legacy…
Recently, I managed to deploy several OSS artifacts built with Bazel to a Maven Central repository. As this process is quite complicated and involves many steps, I’ve decided to write a detailed step-by-step guide. I sure would have liked to have had one before I got started.
I work at Wix, as part of the data-streams team, that is in charge of all our Kafka infrastructure. Recently we started to open source our tools and libraries, starting with Greyhound — a Scala/Java High-level rich SDK for Apache Kafka.
Greyhound is built with Bazel — an open source build tool designed…