# EnqueueZero Techshack 2019-08

# The Curious Case of BEAM CPU Usage

stressgrid.com (opens new window)

Key takeaway is BEAM’s busy wait settings do have a significant impact on CPU usage. The highest impact was observed on the instance with the most available CPU capacity. When running BEAM on an OS kernel shared with other software, it makes sense to turn off busy waiting, to avoid stealing time from non-BEAM processes. It would also make sense to not use busy waiting when running on burstable performance instances in the cloud.

# Cloud Native Application Architecture

medium.com (opens new window)

Principles:

  • Designed As Loosely Coupled Microservices;
  • Developed With Best-of-breed Languages And Frameworks;
  • Center Around APIs For Interaction And Collaboration;
  • Stateless And Massively Scalable;
  • Resiliency At The Core Of the Architecture;
  • Packaged As Lightweight Containers And Orchestrated;
  • Agile DevOps & Automation Using CI/CD;
  • Elastic — Dynamic scale-up/down.
  • Strategies for implementing resiliency:
    • Retry transient failures ;
    • Load balance across instances ;
    • Degrade gracefully;
    • Throttle high-volume tenants/users;
    • Use a circuit breaker;
    • Apply compensating transactions.

# Will Node.js forever be the sluggish Golang?

levelup.gitconnected.com (opens new window)

Express.js is the oldest web framework for Node.js, building on top of out-of-box features Node.js provide, adding a nice App-centered programming interface to manage URL routes, parameters, methods and the like. Though it's very slow.

uWebSockets.js (opens new window) is an alternative web framework for JavaScript backends, written in ~6 thousand lines of C and C++, surpassing in performance the best of Golang by a large margin.

# An update about Redis developments in 2019

antirez.com (opens new window)

Redis roadmap 2019: RESP3, ACL, Multi threading, Better persistence, Data structures.

# How we used delayed replication for disaster recovery with PostgreSQL

about.gitlab.com (opens new window)

Delayed replication can be used as a first resort to recover from accidental data loss and lends itself perfectly to situations where the loss-inducing event is noticed within the configured delay. However, Replication is not a backup mechanism.

Delayed replication is the idea of applying time-delayed changes from the WAL. That is, a transaction that is committed at physical time X is only going to be visible on a replica with delay d at time X + d.

  • A cold backup is useful to recover from a disaster.
  • The purpose of replication is mostly to guard database availability against failures of individual database servers and to distribute load.

# The curse of the data lake monster

thoughtworks.com (opens new window)

Software is best developed in thin, vertical slices that emphasize use cases and user outcomes, and data-intensive projects are no exception.

Data lake often implies a centralized repository of data, or something built and maintained by data engineers so that data scientists can consume data and focus on developing ML use cases etc. Designing a data lake in a top-down fashion, without an eye on the end use cases, will almost inevitably result in a poor problem/solution fit.

The article proposed a more bottom-up approach to realizing the data lake — one that builds one vertical slice at a time. There’s no single, one-size-fits-all definition of a data lake. You need to work on articulated use-cases and measurable business goals.