Photo by Héctor J. Rivas on Unsplash

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.

Forking any 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 raceWith, zipPar, 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…

Photo by Glen Carrie on Unsplash

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.

Photo by Jelle de Gier on Unsplash

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…

Photo by Belinda Fewings on Unsplash

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.

1. Check if what you require isn’t open-sourced already

How to Search

Before jumping into the deep water of…

Photo by Kyle Hinkson on Unsplash

Recently I had the privilege of sitting down with Confluent’s Tim Berglund to discuss how Wix developers use Apache Kafka at scale in a unique way.

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.

Most of…

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.

Photo by Braden Collum on Unsplash

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:

4. Schedule and Forget

…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.

Photo by Denys Nevozhai on Unsplash

1. Consume and Project

…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…

Photo by Franck V. on Unsplash

Recently, I managed to dramatically reduce the memory usage of a widely-used JVM app container on Kubernetes and save a lot of money. I figured out which JVM flags are more important, how to set them correctly and how to easily measure the impact of my actions on various parts of the app’s memory usage. Here are my Cliff notes.

The story starts with a use case. I work at Wix, as part of the data-streams team, that is in charge of all our Kafka infrastructure. Recently I was tasked with creating a Kafka client proxy for our Node.js services.

Use Case: Kafka client sidecar with a wasteful memory usage

Natan Silnitsky

Backend Infrastructure Developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store