IT Blog

👉 Read First: A Brief Overview of Caching Caching is one of the easiest ways to increase system performance. Databases can be slow (yes even the NoSQL ones) and as you already know, speed is the name of the game. If done right , caches can reduce response times, decrease load on database, and save costs. There are several strategies and choosing the right one can make a big difference. Your caching strategy depends on the data and data access patterns . In other words, how the data is written and read. For example: is the system write heavy and reads less frequently? (e.g. time based logs) is data written once and read multiple times? (e.g. User Profile) is data returned always unique? (e.g. search queries) A caching strategy for Top-10 leaderboard system for mobile games will be very different than a service which aggregates and returns user profiles. Choosing the right caching strategy is the key to improving performance. Let’s take a quick look at various caching strat

Leader election and Sharding Practices at Wix microservices 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. For example when it initializes an internal cache from data retrieved from a different service. There are also many cases where events and actions have to be processed in an atomic manner such that the stored data remains valid. E.g. changing account balance or updating inventory. In this blog post, we will explore various practices used by Wix microservices that ensure atomic operation for upda

4 Microservices Caching Patterns at Wix 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 performing a costly query to a DB, or HTTP request to a Wix service or a 3rd party service. It will also reduce the needed scale to service these costly requests. It will also improve reliability, by making sure some data can be returned even if aforementioned DB or 3rd party service are currently unavailable. Below are 4 Caching patte

6 Event Driven Architecture Patterns — Part 2 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 to some schedule. One example is Wix Payments Subscriptions Service that manages subscription-based payments (e.g. subscription to Yoga classes). For each user that has a monthly or yearly subscription, a renewal process with the payment provider has to take place. To tha