Forem: Apoorv Tyagi

Recently, I tried to inspect our Dockerfile to understand our container setup. But there wasn’t one. Instead, we were using Jib - a tool that builds optimized Java container images without Dockerfiles or even Docker. Here’s a complete deep dive 👇

Apoorv Tyagi — Tue, 10 Mar 2026 14:39:22 +0000

Apoorv Tyagi

Mar 10

What is Jib? A Complete Guide to Java Containerization Without Dockerfiles

#devops #docker #containers #beginners

Comments

4 min read

What is Jib? A Complete Guide to Java Containerization Without Dockerfiles

Apoorv Tyagi — Tue, 10 Mar 2026 14:33:30 +0000

Introduction

When I joined PayPay, one of the first things I tried to understand was how our services were containerized.

A common exercise when joining a new backend team is to look at the Dockerfiles used across services as they often reveal interesting patterns:

Which base images are used
Whether the builds are optimized
If multi-stage builds are implemented
Opportunities for reducing image size or improving caching

So naturally, I went looking for the Dockerfile.

But to my surprise… I couldn't find one.

After digging a bit deeper, I realized something interesting. The project wasn’t using a Dockerfile at all. Instead, it was using Jib.

📦 Enter Jib

Imagine shipping a Java microservice where changing a single line of code doesn’t force your CI pipeline to rebuild a massive container image.

That’s exactly what Jib enables.

Jib is an open-source container image builder for Java applications that:

Eliminates the need for a Dockerfile
Does not require a Docker daemon
Integrates directly with Maven and Gradle

Instead of packaging your application as a single fat layer, Jib understands Java project structure and splits your application into optimized layers:

Runtime (base image)
Dependencies
Resources
Application classes

Because of this layered structure, when you change only your application code, only the top layer is rebuilt and pushed.

The result?

⚡ Faster builds
🧱 Better caching
🚀 Simpler CI pipelines
🔧 Less Dockerfile maintenance

In this post, we'll explore how Jib works, when to use it, and how it compares to traditional Dockerfiles.

🚀 What is Jib?

If you build Java applications and ship containers, you’ve probably written Dockerfiles like this:

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/app.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

It works.

But it’s not optimized for Java.

This is where Jib changes the game.

🧱 The Problem With Traditional Docker Builds

Before Jib, containerizing Java apps required:

Writing and maintaining Dockerfiles
Installing Docker everywhere (including CI)
Packaging fat JARs
Rebuilding full images for small code changes
Manually optimizing layers

Even a small code change could invalidate caching and rebuild everything.

That’s inefficient.

🧠 How Jib Works

Jib builds container images by splitting your app into logical layers:

Base Image (JRE)
Dependencies
Resources
Application classes

This means:

If dependencies don’t change → layer reused
If only code changes → only top layer rebuilt

This drastically improves CI speed.

🛠️ Getting Started with Jib

Maven Setup

Add this to your pom.xml:

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <version>3.4.0</version>
  <configuration>
    <to>
      <image>ghcr.io/yourorg/yourapp</image>
    </to>
  </configuration>
</plugin>

Build & push:

mvn compile jib:build

Gradle Setup

plugins {
  id("com.google.cloud.tools.jib") version "3.4.0"
}

jib {
  to {
    image = "ghcr.io/yourorg/yourapp"
  }
}

Build:

./gradlew jib

⚔️ Dockerfile vs Jib - Which Is Better?

This is the real question.

The answer depends on some of the use cases.

✅ When Jib Is Better

1. Standard Java Microservices

Spring Boot
Micronaut
Quarkus
Plain Maven/Gradle apps

Jib integrates directly with your build system.

2. Faster CI/CD Pipelines

Jib:

Does not require a Docker daemon
Builds incremental layers
Pushes smaller diffs
Produces reproducible builds

If CI time matters, Jib usually wins.

3. Developer Simplicity

No Dockerfile. No manual layering. Less DevOps friction.

🏗️ When Dockerfile Is Better

1. OS-Level Customization

If you need:

apt-get install
Native libraries
Custom shell scripts

Jib does not support arbitrary RUN commands.

Dockerfile wins here.

2. Polyglot Applications

If your container includes:

Node + Java
Python + Java
Multiple build tools
Custom entrypoints

Dockerfile provides full flexibility.

3. Complex Multi-Stage Builds

Example:

Compile native binaries
Build frontend assets
Run security scans during build
Copy artifacts between stages

Dockerfile is more powerful here.

📊 Side-by-Side Comparison

Feature	Jib	Dockerfile
Requires Docker daemon	❌ No	✅ Yes
Requires Dockerfile	❌ No	✅ Yes
OS Customization	❌ Limited	✅ Full
Java Layer Optimization	✅ Automatic	❌ Manual
CI/CD Simplicity	✅ High	⚠️ Medium
Multi-language builds	❌ No	✅ Yes
Learning Curve	Low	Medium

🎯 Real-World Scenarios

Scenario A: 20 Spring Boot Microservices

Kubernetes
GitHub Actions
CI cost matters

👉 Jib is usually the better choice.

Scenario B: Enterprise App With Native Dependencies

Custom Alpine base image
OS packages
Hardening scripts
Multi-stage builds

👉 Dockerfile is better.

Scenario C: Small Startup Team

Java-only stack
No DevOps team
Want fast pipelines

👉 Jib simplifies everything.

🔬 Performance Insight

Because Jib separates dependencies and classes:

Code-only changes rebuild in seconds
Docker layer cache invalidation is minimized
CI builds are more predictable

In large microservice ecosystems, this adds up significantly.

🚀 Closing Thoughts

Jib is optimized for:

Java developer productivity.

Dockerfile is optimized for:

Infrastructure control.

If you build modern Java microservices → Start with Jib.

If you need deep OS-level control → Use Dockerfile.

Containerization doesn’t have to be complicated. If your stack is Java-centric and you value speed, reproducibility, and developer autonomy, then Jib is one of the smart tools you can adopt today.

Kafka Consumer Container Restarts in Kubernetes: A Production Case Study

Apoorv Tyagi — Wed, 11 Feb 2026 14:22:39 +0000

Background

At my current org, I got introduced to a very fun tool, PagerDuty - because who doesn't love being woken up at 3:31 AM?

A similar alert flared up for one of our merchant services. While it mercifully avoided the 3 AM slot, the diagnostic was clear: The containers running were restarting. There’s no bad deployment, just a burst of events on a Kafka topic and a trail of exit code 137.

This is the story of how we tracked down the memory issue in one of our core merchant services at PayPay that wasn't exactly a leak, but a partition mismatch, and a battle between Garbage Collectors.

The Incident: When Bursts Turn Into Crashes

It started with a Kafka topic.

This topic powers merchant payouts in Japan and, on average, processes around 3,500 messages per day. On paper, that volume sounds harmless. In reality, the traffic pattern was anything but smooth. Instead of being evenly distributed, most of those messages arrived in short, aggressive bursts.

And that’s when things began to fall apart.

Every time a burst hit, our merchant service pods would suddenly spike in memory usage. Within minutes, they would hiy their memory limit and get terminated by Kubernetes with an OOMKill.

The Investigation

When we looked at the consumer topology, the first red flag was almost too obvious to ignore:

Kafka partitions: 6
Active consumer pods: 10

In Kafka, this setup has a very specific behavior. A single partition can be consumed by only one consumer within a consumer group. So with 6 partitions and 10 pods, 4 pods were effectively idle, waiting on the sidelines.

Every burst of messages was being funneled into just 6 pods, concentrating the entire load on 60% of our fleet, while the remaining pods contributed nothing. Under normal traffic, this imbalance went unnoticed. But during bursts, those active pods suddenly did significantly more work than they were sized for.

That explained where the pressure was landing, but not why it was causing hard crashes.

To answer that, we moved to the next step: capturing a heap & thread dump in our staging environment while simulating a 5X production load. And that’s where things started getting really interesting.

The ZGC Struggle

We were initially running the service on ZGC.

On paper, ZGC is impressive - microsecond-level pause times and near-zero stop-the-world events. But what often gets missed is its biggest trade-off: ZGC needs a lot of breathing room. It relies heavily on having heap memoryto keep allocation and reclamation in balance.

When we profiled the system, the numbers told a worrying story. The old-generation worker alone had consumed over 584 seconds of CPU time. ZGC wasn’t idle - it was working relentlessly, trying to keep up with a flood of newly allocated objects.

But it simply couldn’t reclaim memory fast enough.

The heap kept expanding, allocation pressure kept rising, and eventually the pod crossed its memory limit and was OOMKilled. Low pause times didn’t matter if the process couldn’t stay alive long enough to benefit from them.

The Substitute: G1GC

At this point, we decided to switch strategies and flipped the JVM to G1GC, then reran the same load test.

The difference was immediate:

Memory usage: Stabilized under 1 GiB (previously went up all the way to 3 GiB)
Pause times: Increased slightly to around 35 ms, still comfortably within our SLAs
Stability: No crashes. No restarts.

G1GC traded a bit of pause time for predictable memory behavior, which turned out to be exactly what this workload needed. In a burst-heavy system, consistency beats theoretical best-case latency every single time.

The Side-Quest: The Slack Notifier "Leak"

While digging through the thread dumps, we found a "Red Herring." Our SlackNotifier class, which is responsible for sending failure alerts, was instantiating a new OkHttpClient for every single error notification.

Each OkHttpClient spins up its own connection pool and thread pool. In a high-error scenario, this could have quietly expanded into dozens, if not hundreds, of threads, steadily pushing the JVM toward thread exhaustion and memory pressure.

Interestingly, this wasn’t the direct cause of the production crashes. During the Kafka bursts, no errors were actually being emitted, which meant this code path wasn’t even executed. But left unfixed, it was a ticking time bomb waiting for the next incident.

The fix was straightforward: refactor the notifier to use a single, shared OkHttpClient singleton, ensuring controlled resource usage and predictable behavior.

Not the root cause, but a critical cleanup uncovered at exactly the right time.

Final Fixes

To stabilize Merchant Finance, we didn’t just tweak application code—we re-aligned the infrastructure to match the workload it was actually handling.

Here’s what we changed.

1. Memory Alignment

We set memory.request to match memory.limit at 3 GiB.

This ensured the node reserved the full memory upfront, eliminating eviction pressure during bursts and preventing Kubernetes from stepping in with an OOMKill when memory usage spiked. [A reddit thread worth exploring]

2. Partition Scaling

We scaled the Kafka topic from 6 partitions to 10.

This change ensured that every merchant service pod became an active consumer, evenly distributing the workload instead of concentrating it on a subset of the fleet. Burst traffic stopped being a stress test for a few pods and became a shared responsibility across all of them.

3. The GC Switch

We officially moved this service to G1GC.

For this workload profile, we chose predictable memory behavior over ultra-low pause times. Slightly higher pauses were a small price to pay for stability under burst-heavy traffic.

4. CPU Buffering

We increased the CPU request from 100 millicores to 500 millicores.

This wasn’t about average CPU usage; it was about headroom. During peak allocation and garbage collection cycles, G1GC needs consistent CPU availability to do its job efficiently. An under-provisioned CPU would only delay GC work and amplify memory pressure.

5. Fixing SlackNotifier

Finally, we refactored SlackNotifier to use a single shared OkHttpClient instance instead of creating a new one per notification.

It wasn’t the root cause, but it removed a hidden risk that could have turned a future incident into something far worse.

Results

After applying the infrastructure and JVM changes, we reran the same burst-heavy load tests and monitored JVM, Kubernetes, and Kafka metrics.

The difference wasn’t subtle 👇

1. JVM Behavior (ZGC v.s. G1GC)

GC pause frequency dropped significantly
GC avg pause times increase

The change is clearly visible around 12:00–12:10, which is when the GC and infrastructure updates were applied.

2. G1GC Under Load

Switching away from ZGC did increase pause times, but well within acceptable limits.

Average GC pause: ~30–40 ms
Consistency: Flat, predictable, no spikes
Impact: No effect on SLAs

This was an intentional trade-off. We gave up ultra-low pause times in exchange for a lower GC pause count and memory predictability.

3. Kubernetes Pods Stopped Restarting

From a platform perspective, this was the most important outcome.

Pod restarts: 0
OOM events: None
Memory usage: Stable across all pods
CPU usage: Predictable, with sufficient headroom during GC cycles

Container-level metrics after the fixes - memory usage remains stable, CPU has sufficient headroom, and pod restarts drop to zero.

4. Kafka Kept Up With Bursts Without Errors

Finally, we looked at the Kafka side of the system.

Consumer lag: Spiked briefly during bursts, then drained smoothly
Consumer latency (P95): Stable
Errors: None observed
Throughput: Fully sustained during burst windows

Increasing the partition count ensured every pod actively participated in consumption, preventing load concentration and smoothing out processing during spikes.

Kafka consumer metrics during burst traffic. Lag increases temporarily but recovers quickly, with no errors and stable latency.

Final Outcome

After all fixes were applied:

✅ No pod restarts during burst traffic
✅ No OOMKills
✅ Predictable JVM behavior under load
✅ Kafka bursts handled without errors

Resilience isn’t just about handling errors after they happen, it’s about understanding how your system behaves under load.

If you’re running JVM workloads on Kubernetes, it’s worth taking a hard look at both your garbage collector choice and your resource requests versus limits. These decisions don’t show their impact during steady state traffic, but they matter enormously when load arrives in bursts.

Sometimes, the “latest and greatest” option isn’t the right fit for every workload. Stability often comes from choosing the tool that behaves predictably under stress, not the one that looks best on paper.

In production, boring and predictable almost always win.

How we solved cache invalidation in Kubernetes with a headless service

Apoorv Tyagi — Mon, 29 Dec 2025 06:45:00 +0000

⬅️ Background

At my previous organization, we were building a health platform, and one of the most critical, high-traffic components was our Lab test booking service. One of its core functions is to serve package details like inclusions, prices, and provider information for thousands of user requests daily.

The initial architecture was simple: every single request meant a new query to a database. As traffic scaled, our database struggled. Latency spiked, and CPU usage became a constant concern.

With mostly static data that rarely changes, the clear solution was to cache it. But the execution is where we got creative. This is the story of how we implemented a zero-cost, in-memory cache in our Node.js microservices and used a Kubernetes feature, “The Headless Service” to handle distributed cache invalidation flawlessly.

🛑 The Problem: Fast Caching & Scalable Invalidation

We decided on in-memory caching using a library like @nestjs/cache-manager to slash DB load and boost response times. However, in a Kubernetes cluster, where our service runs across multiple, dynamic pods, this creates a major headache: Cache Inconsistency.

If an admin updates a package price in the MySQL database, only the single pod that handled the write sees the change immediately. The other pods are serving users stale data - consistency, gone*.*

Furthermore, Kubernetes pod IPs are temporary. They change during restarts, deployments, and scaling events. We couldn't rely on hardcoded lists. Our invalidation system needed a reliable way to discover every running pod at the exact moment of a data update.

We needed a broadcasting mechanism.

🛠️ The Solution: The K8s Headless Service

Our strategy was a hybrid approach: local caching for performance, and a targeted internal HTTP broadcast for invalidation.

Step 1: Headless Services for Pod Discovery

This is the key to the whole solution. A standard Kubernetes service acts as a load balancer with a single Virtual IP. But a Headless Service is different. By setting clusterIP: None in the Service manifest (.spec.clusterIP), Kubernetes skips the load balancer and, crucially, returns a list of individual DNS A records for every active pod’s IP address.

Here is the simple(yet powerful) Headless Service manifest we deployed:

apiVersion: v1
kind: Service
metadata:
  name: booking-service-headless
spec:
  clusterIP: None             # THE TRICK: Makes it Headless
  selector:
    app: booking-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000

Now, when we resolve booking-service-headless.default.svc.cluster.local, we get an array of all current, healthy pod IPs.

For visualization, here's a diagram of Headless Services in action:

Step 2 & 3: Broadcast Implementation

In the next step, we added kubectl into our Docker image for API queries. This gives the pod the power to query the Kubernetes API directly.

To implement this safely, we followed the Principle of Least Privilege. We created a dedicated ServiceAccount for our booking service and bound it to a specific Role using RBAC (Role-Based Access Control). This Role was strictly limited: it only allowed the list and get operations on the endpoints resource within its own namespace. This ensures that even if a pod is compromised, an attacker cannot delete resources or view sensitive secrets.

Second, we created a simple, internal /invalidate-cache API endpoint on our booking service. When we hit this endpoint, it clears a specific cache key (passed in the request body) using the in-memory cache’s del() method.

When an admin update happens, and the data is written to MySQL, the pod that handles the write executes a bash script using kubectl and curl:

It uses kubectl to get the list of IPs from the Headless Service endpoints, then sends a direct HTTP POST request to the internal /invalidate-cache endpoint on each pod.

# Executed by the Node.js process on update
pod_ips=$(kubectl get endpoints listing-headless-service -o jsonpath='{.subsets[0].addresses[*].ip}')

for ip in $pod_ips; do
   curl -X POST http://$ip:3000/v2/invalidate\
       -H "Content-Type: application/json" \
       -d '{"key": "package-123"}' # Clears the specific key
done

This ensures the system is:

Dynamic: The IP list is fresh at invalidation time, handling upscaling, downscaling and restarts seamlessly.
Targeted: We clear only the stale package key, maximizing cache retention.
Cost-Effective: Zero new service bills.
Reliability: Add curl retries and logging for failed broadcasts.

For those looking to keep their Docker images clean, you can avoid installing kubectl and curl entirely by using the official @kubernetes/client-node library. By using the library, your Node.js process can query the Kubernetes API directly from within the code. This makes the logic more testable, allows for better error handling, and removes the overhead of spawning shell processes. It turns your infrastructure logic into standard application code.

📈 Production Results and Takeaways

Post-rollout, our MySQL database load has consistently remained low, and our cache hit rate has remained above 95%+. We have had zero reported incidents of users seeing stale package data. The Headless Service trick proved robust, even during high-traffic deployments.

This solution proves that sometimes, the most elegant and cheapest solution isn't an expensive managed service, but a creative application of your existing tools*.* It’s about being smart with your infrastructure, not just throwing money at the problem.

Going Vernacular: Engineering Our Way to Process Multilingual Names

Apoorv Tyagi — Mon, 04 Dec 2023 06:30:00 +0000

Introduction

At our current organization, earlier this year as we were looking at the errors at one of our signup API, we observed that nearly 5% of our requests were getting failed, all due to 400 BAD REQUEST errors, and the root cause was traced back to a regex check.

This regex was a constraint that our system allows only English characters for users to input their first and last names, yet many individuals opted to enter their names in their native languages. Particularly, these customers were the people who were interested in purchasing health policies from our platform hence making them a crucial segment of our user base.

In response to this, we decided to address the 5% case by enabling users to enter their names in any language they preferred. However, this brings up a lot of challenges that we need to solve.

Challenges

1. Data Storage Strategy

We rely on MongoDB for storage and retrieval of user names. While MongoDB allows storage for all UTF-8 compatible characters, the problem comes when dealing with search. For English names, our search operations utilize the simple collation method. The corresponding fields are appropriately indexed to optimize query performance.

While the option to implement a collation index for other languages also exists in MongoDB, this approach necessitates informing DB about the specific language for which we intend to search. The challenge here is that our user base spans many languages, with India alone having more than 20 diverse languages.

Since our objective was to extend support to at least all Indian languages, implementing collation indexes for every supported language would lead to an increased number of indexes and hence an increase in index size over time as well.

Additionally, this approach would place the responsibility on developers to remember to add an index for each new language as our language support expands, which is far from an efficient solution.

2. API Gateway Constraint

All our APIs are exposed behind an API gateway and just before the gateway forwards a request to the respective API service, an inbound policy verifies the user's authentication status. Once the user is authenticated, it retrieves basic user details such as name, mobile number, and other metadata, and appends it to a request header of that API.

A multitude of APIs rely on this user-specific data in headers for their further processing.

However, there's a restriction imposed by the gateway – it allows only ASCII characters for processing and inclusion in the headers. So we had to make sure even though the name is in any other language, the response we share must be exclusively in English.

Also, this process must remain fast, as any delay in authentication could lead to sluggish API performance.

3. External Partners' Challenge with Vernacular Names

Even if we started to accept names in multiple languages, there were our partners who had to accept those names from us. If they don't support multilingual names, the user journey breaks. One such was our payment partner. We had to make sure our payments team always received the English name even when users provided names in other languages.

Also, we wanted to avoid those annoying pop-ups prompting users to enter their names in English whenever we needed to. So keeping these problems in mind we had to build a viable solution.

Solutioning

While utilizing a third-party transliteration service might have been the easiest route, we opted to develop an in-house solution to control costs and maintain full control.

Considering the API gateway and the requirements of payment partners, it became clear that we needed to transform non-English names into English equivalents. However, presenting this English name to the user was counterintuitive – for example entering a name in Hindi, only to see it transformed into English upon logging in seemed contradictory.

Therefore, we developed a dual-naming strategy. The original fields, "firstName" and "lastName" would retain the user-entered names in their entered language, while we introduced two additional fields, "englishFirstName" and "englishLastName" dedicated to storing the English counterparts of these names. These English names could then be shared with the API gateway and our payment partners.

Coming back to the challenge of storing these names efficiently, we anticipated that managing collation indexes as the number of supported languages grew would become unmanageable. Additionally, searching would require specifying the collation for each query, creating an added layer of complexity. Hence, we decided to pivot away from this approach.

Our second approach involved using Unicode. As we aimed to support multiple languages without constraint, we recognized that Unicode could effectively represent characters in nearly every language. Consequently, we decided to store Unicode representations for first and last names in their respective MongoDB fields.

We just added another layer between our DB and the application that converts these Unicode strings to the original values in the local language while retrieving the names from DB and converting the local names to their respective English names for storing them in englishFirstName and englishLastName at the time of any insert or update.

This strategy provided the flexibility we needed to manage multilingual names seamlessly.

Key Design Considerations

1. Unicode Optimization

Unicode representation typically comprises a 6 character string, with 'a' represented as 'U+0061' and 'P' as 'U+0050,' commonly commencing with 'U+00.' To conserve space in our database storage, we opted to omit the 'U+' prefix and leading zeros, optimizing our data storage.

2. Transliteration vs. Translation

Initially, our aim was transliteration, which requires converting names from one script to another while retaining their phonetic sound. For example, the Hindi word "प्रतीक्षा" should be transformed to "Partiksha" and not translated to its English equivalent i.e. "Wait". However, we recognized that Google Translate primarily focuses on translation, not transliteration. Again we didn't want to go directly for the paid Google transliterate service in our first iteration hence we developed our transliteration service using the free version of Google translate.

3. Contextual Enhancements

Another and the most crucial observation that we had was providing context to the Google Translate API that influenced its responses. To leverage this, we experimented with adding statement prefixes to non-English names to establish context. After a few hits and trials, we realized that for shorter names (less than 5 characters), a more extensive prefix statement didn't yield desirable results, and Google often returned the same Hindi word. For longer names, we employed lengthier statements, determining the optimal balance through trial and error.

Translating names normally led to their literal translation. For example "प्रतीक्षा" to "Wait" instead of "Pratiksha":

Adding a prefix statement corrected it:

Initial Code

After our first iteration, we developed the below code for transliteration. Here we are using the @iamtraction/google-translate library which is a wrapper written over free Google translate API.

const translate = require('@iamtraction/google-translate');

function getGoogleTranslateText(localName) {
  /*
    Adding an English sentence before the name so that
    it doesn't get translated to its literal meaning.
    For eg परीक्षा to Exam instead of Pariksha.
  */
  if (localName.length <= 5) {
    return `name: ${localName}`;
  }
  return `your name is: ${localName}`;
}

async function translateNameToEnglish(localName) {
  if (localName.match(/^[a-zA-Z ]+$/i)) {
    // If the name is already in English just return
    return localName;
  }
  try {
    const res = await translate(getGoogleTranslateText(localName), {
      to: 'en',
    });
    const translatedName = res.text.split(':')[1].trim();
    return translatedName;
  } catch (err) {}
  // In case of error, Return the Unicode string
  return localName;
}

Beta Release and Production Challenges

Once we built this, we released the feature in beta, and approximately 250 users signed up with non-English names within the first few days.

Upon simple eyeballing on translated texts, we found out that the process of converting the name from its local language to Unicode was working perfectly fine and users were able to view their names properly in the application in the language they preferred but we identified two issues as far as the process of transliteration to English was concerned:

Some names were incorrectly transliterated. This occurrence could be attributed to our dependence on Google Translate, a general translation service, rather than a specialized transliteration service.
Some names remained unaltered and were not transliterated. These names were returned in the same language as the original one. This meant adding context with prefix sentences before the translation was causing problems for specific names.

This prompted a further investigation that led us to another npm package called "unidecode," which converts Unicode to the original string. While initial tests with unidecode showed accuracy, they also revealed minor spelling discrepancies. In contrast, Google consistently delivered translations with correct spellings. We just needed to find a way of using the best of both worlds.

Hence, we incorporated unidecode into our algorithm as part of our solution.

Improved Solution

const translate = require('@iamtraction/google-translate');
const unidecode = require('unidecode');
const { isAlmostEqualStrings } = require('./levenshtein');
/**
 *
 * @param {String} localName
 * @description Generates text for Google (shorter statement context for short names) based on localName length
 * @returns {String} returns text to translate
 */
function getGoogleTranslateText(localName) {
  /*
    Adding an English sentence before name so that
    it doesn't get translated to its literal meaning.
    For eg परीक्षा to Exam instead of Pariksha.
  */
  if (localName.length <= 5) {
    return `name: ${localName}`;
  }
  return `your name is: ${localName}`;
}

/**
 *
 * @param {String} localName
 * @description Give an ALMOST transliterated name
 * @returns {String} returns a converted transliterated name from the local language
 */
function transliterate(localName, googleTranslatedName) {
  const decodedName = unidecode(localName);
  if (
    decodedName &&
    Array.from(decodedName)[0]?.toLowerCase() !==
      Array.from(googleTranslatedName)[0]?.toLowerCase() &&
    !isAlmostEqualStrings(decodedName, googleTranslatedName)
  ) {
    return decodedName;
  }
  return googleTranslatedName;
}

/**
 *
 * @param {String} Input non English string
 * @description translates non-english string to English
 * @returns {String} returns translated string
 */
async function translateNameToEnglish(localName) {
  if (!localName || localName.match(/^[a-zA-Z ]+$/i)) {
    // If name is already in English just return
    return localName;
  }
  try {
    const res = await translate(getGoogleTranslateText(localName), {
      to: 'en',
    });
    const translatedName = res.text.split(':')[1].trim();
    return transliterate(localName, translatedName);
  } catch (err) {}
  // In case of error, Return original string
  return localName;
}

After obtaining the translated name, we feed it into the recently introduced transliterate function. Inside this function, our initial step involves extracting the decoded string using the Unidecode library. However, the crux of the matter arises: How do we determine which result to prioritize, i.e., the decoded string or the translated string?

To tackle this, we implemented Levenshtein Distance, an algorithm that calculates the similarity between two strings.

Initially, we check if the first character of the decoded name matches the first character of the translated name. If it's not, then for sure the translated name was incorrect hence we return the decoded name, even though it might contain minor spelling discrepancies it's better to use that than the incorrect translation.

If it does match then we go for the Levenshtein Distance algorithm.

The Levenshtein distance is a number that tells you how similar two strings are. The higher the number, the more dissimilar the two strings are

In the implementation, we have a function isAlmostEqualStrings that generates a value from 0 to 1 and returns true if the value is above a certain threshold. In our case, we set the threshold to 0.8

If the Levenshtein distance indicates a match exceeding 80%, we return the translated name; otherwise, we return the decoded name. This approach ensures that we prioritize accuracy, offering a reliable result based on the established similarity threshold.

This updated algorithm substantially reduced the above mentioned issues. Even though it's not 100% accurate it solved our 5% cases very well.

Conclusion

The algorithm developed was entirely in-house and incurred no costs. While investing in a paid solution might have potentially offered better results, wise engineering decisions taken iteratively and a handful of clever hacks played a vital role in both reducing costs and efficiently resolving the specific problem we had.

The complete code for the above implementation along with the Levenshtein Distance algorithm can be found on GitHub (contributions/corrections are welcome).

With this, we come to the end of the article. My DMs are always open if you want to discuss further on any tech topic or if you've got any questions, suggestions, or feedback in general:

Happy learning!

How to Keep Your Package Dependencies Up to Date on Azure DevOps

Apoorv Tyagi — Sun, 03 Dec 2023 13:30:00 +0000

As a developer, how often have you seen a repository with packages that are out of date?

New package updates generally include new features, performance improvements, and security fixes. But keeping track of all outdated dependencies in your project can be really boring and a time consuming task, especially if you have lots of them.

So to do this sort of housekeeping, I tried out Dependabot.

How Dependabot Works

Dependabot goes through the dependency files of your project. For instance, it searches your package.json or pom.xml files and inspects for any outdated or insecure dependencies. If it finds any, it opens individual pull requests to update each one of them.

This tool is natively integrated with GitHub. But recently, I had to solve this problem of updating dependencies for a project running in Azure DevOps. So I decided to find a workaround to integrate Dependabot with Azure Pipelines. In this blog post, I will share my solution.

If you go to Azure DevOps Extension Marketplace and search for "Dependabot", you will find an extension by Tingle Software. Using this extension we can easily integrate Dependabot with our repos in Azure DevOps.

You can check if you have this extension in your "Organization Settings" in Azure DevOps. If not, make sure you have it installed before proceeding.

Installed Extensions - Azure DevOps

How to Create the Azure Pipeline

Let's now start with creating a new YAML file for your Azure pipeline:

trigger: none

stages:
  - stage: CheckDependencies
    displayName: 'Check Dependencies'
    jobs:
      - job: Dependabot
        displayName: 'Run Dependabot'
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: dependabot@1
            displayName: 'Run Dependabot'
            inputs:
              packageManager: 'npm'
              targetBranch: 'develop'
              openPullRequestsLimit: 10

In the task parameters, I have specified three params:

packageManager: It specifies the type of packages to check for dependency upgrades. Examples: nuget, maven, gradle, npm, and so on.
targetBranch: It is an optional parameter that defines the branch to be targeted when creating pull requests. When not specified, Dependabot will pick the default branch of the repository.
openPullRequestsLimit: This is again an optional parameter that specifies the maximum number of open pull requests to have at any one time. By default, it opens 5 pull requests at a time.

You can go through all the Task Parameters that the extension supports to tweak your implementation. Now just simply configure this YAML file with a new azure pipeline and then you're ready to run it.

Pipeline Configuration - Azure DevOps

The next step is to give your repository's Project Collection Build Service access so that Dependabot can create the pull request to your project's repositories.

For that, go to your project settings. Here, you click on the repositories and search for the repo where you have integrated the pipeline.

After you have selected that, click on the security tab and search for project collection build service. You have to allow the following access to it:

Contribute
Contribute to pull request
Create Branch
Create Tag
Force Push

Access to raise PR in Repo

With this, you're completely ready to run the pipeline. Once you do it, you'll start receiving pull requests in your repository with the updated packages.

PR raised by Dependabot

How to Schedule the Pipeline

Up to this point, you've had to manually trigger the pipeline to run. To make it run automatically, you can configure schedules for your pipelines. This will trigger your pipeline to start based on a schedule.

Use the following syntax and add it to the very top of your YAML file:

schedules:
- cron: string
  displayName: string
  branches:
    include: [ string ]
  always: boolean

The branche*s’* include parameter specifies which branches the schedule applies to.

The always parameter specifies whether to "always" run the pipeline or only if there have been any source code changes since the last successful scheduled run. The default is false.

For this case, you set its value to true as Dependabot updates are independent of any code changes.

The time zone for cron schedules is UTC and cron syntax is as follows:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

So if you want to run your pipeline every week on Sunday at 12pm UTC, you would need to write - cron: "0 12 * * 0" (update the cron to suit your needs).

This is how your final YAML should look like after adding a schedule:

schedules:
  - cron: "0 12 * * 0"
    displayName: Weekly Dependency Updates
    branches:
      include:
      - develop
    always: true

trigger: none

stages:
  - stage: CheckDependencies
    displayName: 'Check Dependencies'
    jobs:
      - job: Dependabot
        displayName: 'Run Dependabot'
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          - task: dependabot@1
            displayName: 'Run Dependabot'
            inputs:
              packageManager: 'npm'
              targetBranch: 'develop'
              openPullRequestsLimit: 10

This pipeline does the following for you:

It runs every week (Sunday 12pm UTC in this case) and looks for any outdated or insecure dependency. If it finds any, it opens pull requests to update each one of them individually.

Hopefully, this will help you to keep your project dependencies up to date in Azure DevOps!

Wrapping Up

With this, we come to the end of the article. My DMs are always open if you want to discuss further on any tech topic or if you've got any questions, suggestions, or feedback in general:

Happy learning! 💻 😄

Finding a Needle in Haystack: Fixing Mysterious Bad Gateway

Apoorv Tyagi — Sun, 12 Mar 2023 06:30:00 +0000

Introduction

At my current org, we have many applications running behind the API gateway that interacts with the outside world using REST APIs. To track server-side failures we built an alert system that nudges every time we get any 5XX error.

As soon as we made the alert system live, we started noticing a few HTTP 502 “Bad Gateway” errors occurring every day but intermittently.

As per RFC7231, the 502 (Bad Gateway) status code indicates that the server while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.

With very little known information, I began chasing down the RCA for these failures.

Debugging

As I started debugging the issue I wanted first to check what was going on in the application at the time when the particular request arrived. However, I discovered that this failed request never reached the server-side application.

We also have a proxy server sitting in between our API gateway and the application so I checked the logs of that as well and fortunately, I was able to track the request there.

I observed the request despite coming from the API gateway, the response sent was 502, without even communicating with my application.

Next, I checked the throughput when such a response was sent as I thought maybe there was a limitation in the number of concurrent requests our application can handle. But the result was again surprising because even when the throughput was < 1000 TPM (Transactions Per Minute), the 502 error persisted and we had already observed our applications working well even at a TPM of well over 5000.

Based on these findings, I realized that issue is not with our application code but with how our proxy server interacts with my application. So I started diving deep into how HTTP connections are made during the request-response cycle.

Diving in TCP Connection

In the realm of web communication, HTTP (Hypertext Transfer Protocol) initiates a unique TCP (Transmission Control Protocol) connection for every request. Setting up a TCP connection requires a three-step handshake process with the server before transmitting data. Once the data transmission is finished, a four-step process is implemented to terminate the same connection.

In some scenarios where limited data is transmitted, the three and four-step processes involved in establishing and terminating TCP connections can add a significant overhead. To address this issue, rather than opening and closing a socket for each HTTP request, it is possible to keep a socket open for a more extended period and leverage it for multiple HTTP requests.

This mechanism is known as HTTP keep-alive, which permits clients to reuse existing connections for several requests. The decision of when to terminate these open TCP sockets is managed by timeout configurations on either the client or target server or both. This approach improves the efficiency of web communication and reduces latency.

An important point here to notice is that for a short amount of time, there is a possibility that a connection can be “half-open”, in which one side has terminated the connection but the other has not. The side that has terminated can no longer send any data into the connection, but the other side still can. The terminating side continues reading the data until the other side terminates as well.

Now coming back to our story, the proxy server acts as a messenger passing requests and responses back and forth. If the service returns an invalid or malformed response, rather than transmitting that meaningless information to the client, the proxy server sends a 502 error message.

This suggests that our application might have attempted to terminate the TCP connection, but the proxy server was unaware of this and continued to send the request to the same socket. This provided us with a critical hint in our investigation.

Debugging, further

The 502 Bad Gateway error could occur when the proxy server sends a request to the application, and simultaneously, the service terminates the connection by sending the FIN segment to the same socket. The proxy socket acknowledges the FIN and starts a new handshake process.

Meanwhile, the socket on the server side has just received a data request referring to the previous (now closed) connection. As it is unable of handling it, it sends a RST segment back to the proxy server. The proxy server then returns a 502 error to the user.

Based on this hypothesis, we found the default HTTP keep-alive time. While the proxy server's keep-alive time was set at 75 seconds, our application had a keep-alive of only 5 seconds. This suggests that after 5 seconds, our application could close the connection, and while this process is ongoing, the proxy server could receive a request. As it has not yet received the FIN, it sends the request down the dead connection, receives nothing in response, and therefore throws a 502 error.

To verify this hypothesis, I modified the HTTP keep-alive timeout of our application to 1 ms in our development environment. We then conducted load testing on our APIs and found a significant number of API failures due to the same 502 error. This confirmed our initial hypothesis.

Fix

A possible solution is to ensure that the upstream (application) idle connection timeout is longer than the downstream (proxy) connection timeout.

In practice, this can be achieved by increasing the keep-alive time of the application server to a value greater than the proxy's connection timeout. For example, in our setup, I have increased the server's keep-alive time from 5 seconds to 76 seconds, which is 1 second longer than the proxy server's connection timeout.

By doing so, the downstream (proxy) server becomes the one to close the connections instead of the upstream server. This ensures that there is no race condition between the two servers and eliminates the possibility of a 502 error caused by a closed connection. Therefore, setting appropriate upstream and downstream timeouts is crucial for the smooth functioning of web applications.

The below example illustrates how to modify the default keep-alive timeout for an Express app:

const express = require('express');
const app = express();
const server = app.listen(3000);

server.keepAliveTimeout = 76 * 1000 // Time in ms

Conclusion

Theoretically, this race condition can occur anytime when the connections are reused & if the upstream service drops connections before the downstream.

In my case, it was the proxy server that pre-connects to all the backend servers, and the TCP connection persists for reusing for further HTTP requests. The Keep-Alive time of this connection was 75 seconds from the proxy and 5 seconds from the app server.

This was causing a condition where the proxy thinks a connection is open, but the backend closes it. And when it sends the request down the same connection, instead of getting the TCP ACK for the sent request, the proxy gets TCP FIN (and eventually RST) from the upstream.

The proxy server then just gives up on such requests and responds immediately with HTTP 502 error to the client. And this is completely invisible on the application side! That's why no application logs were visible to us.

To mitigate this you can either make sure the upstream (application) idle connection timeout is longer than the downstream (proxy) connection timeout OR implement retries on HTTP 5xx errors from the API gateway.

I hope you found it helpful. Comments or corrections are always welcome.

Building Resilient Systems: Retry Pattern in Microservices

Apoorv Tyagi — Fri, 10 Mar 2023 04:10:00 +0000

Introduction

Any application that communicates with other resources over a network has to be resilient to transient failures.

These failures are sometimes self-correcting. For example, a service that is processing thousands of concurrent requests can implement an algorithm to temporarily reject any further requests until its load gets reduced. An application that is trying to access this service may initially fail to connect, but if it tries again it might succeed.

While designing any system it is essential to make it resilient against such failures. In this article, we will look at one of the many ways of achieving it using Retries.

At our current organization, we use this mechanism throughout our microservices to make sure that we handle failures and at the same time, provide the best of our services to our customers.

Let’s start by first defining what we mean by failures.

What is a failure?

Failures can be caused by numerous reasons while our services communicate with each other over a network. Some examples of types of failures are:

A slow response / No response at all
A response in the incorrect format
A response containing incorrect data

In planning for failures, we should seek to handle each of these errors.

Retry

Retry is a process of automatically repeating a request in case any failure is detected. This helps return fewer errors to the users, improving the consumer experience on our application.

The only caveat when it comes to retrying is that multiple requests to the same resource should have the same effect as making a single request i.e the resource should be idempotent.

In REST APIs, GET, HEAD and OPTIONS methods generally do not change the resource state on the server and hence are mostly retryable.

When should we retry a request?

Ideally, we should only retry a failed request when we know it has any possibility of succeeding the next time otherwise it will just be a waste of resources (CPU, Memory, and Time).

For example, you might get an error with status code 503 (Service unavailable) when the server had an unexpected hiccup while connecting to a DB host. A retry may work here if the second call to the upstream service gets a DB instance that is available.

On the other hand, retrying for errors with status code 401(Unauthorised) or 403 (Forbidden) may never work because they require changing the request itself.

The general idea is that if an upstream request fails, we immediately try again, and probably the second request will succeed. However, this will not always benefit us. The actual implementation should include a delay between the subsequent requests. We will discuss that in the next sections.

Problem with normal retries

Consider what happens when we get 100,000 concurrent requests & all hosts of the upstream service are down at that instance. If we were to retry immediately, these 100,000 failed requests would retry immediately on a static interval. They would also be combined with new requests from the increasing traffic and could make the service down again.

This creates a cycle that keeps repeating until all the retries are exhausted and will also eventually makes the upstream service overwhelm, and might further degrade the service that is already under distress. This is a common computer science problem also known as the Thundering Herd problem.

To tackle this, we can introduce some delay in retrying a failed request.

Backoff

The wait time between a request and its subsequent retry is called the backoff.

With backoff, the amount of time between requests increases exponentially as the number of retry requests increases.

The scenario we just discussed above is where having a backoff helps, it changes the wait time between attempts based on the number of previous failures.

From the above figure, let's say the initial request goes at the 0th millisecond and fails with a retryable status code. Assuming that we have set up the backoff time of 200ms and neglecting the request-response time, the first retry attempt happens at 200th milliseconds (1*200ms). If this fails again, the second retry then happens at 400ms (2*200). Similarly, the subsequent retry happens at 800ms till we exhaust all the retries.

If any of the request failures are caused by the upstream service being overloaded, this mechanism of spreading out our requests and retries gives us a better chance of getting a successful response.

Jitter

The Backoff strategy allows us to distribute the load sent to the upstream services. Yet, turns out it isn't always the wisest decision because all the retries are still going to be in sync which can lead to a spike on the service.

Jitter is the process of breaking this synchronization by increasing or decreasing the backoff delay to further spread out the load.

Coming back to our previous example, let’s say our upstream service is serving the maximum load that it can handle and four new clients send their requests which fail because the server could not handle that amount of concurrent requests. With only backoff implementation, let's say after 200 milliseconds we retry all 4 failed requests. Now, these retry requests would also fail again for the same reason. To avoid this, the retry implementation needs to have randomness.

Implementation

Going through this AWS documentation that goes deep into the exponential backoff algorithm, we have implemented our retry mechanism using Axios interceptor

The example is written inside of a Nodejs application, but the process will be similar regardless of which JavaScript framework you’re using.

In this, we expect the following settings:

Total Retries The number of maximum retries you want before returning a failed response to the client.

Retry Status Codes The HTTP status codes that you want to retry for. By default, we have kept it on for all status codes >=500.

Backoff This is the minimum time we have to wait while sending any subsequent retry request.

axios.interceptors.response.use(
  async (error) => {

    const statusCode = error.response.status
    const currentRetryCount = error.response.config.currentRetryCount ?? 0
    const totalRetry = error.response.config.retryCount ?? 0
    const retryStatusCodes = error.response.config.retryStatusCodes ?? []
    const backoff = error.response.config.backoff ?? 100

    if(isRetryRequired({
      statusCode, 
      retryStatusCodes, 
      currentRetryCount, 
      totalRetry})
    ){

      error.config.currentRetryCount = 
          currentRetryCount === 0 ? 1 : currentRetryCount + 1;

     // Create a new promise with exponential backoff
     const backOffWithJitterTime = getTimeout(currentRetryCount,backoff);
     const backoff = new Promise(function(resolve) {
          setTimeout(function() {
              resolve();
          }, backOffWithJitterTime);
      });

      // Return the promise in which recalls Axios to retry the request
      await backoff;
      return axios(error.config);

    }
  }
);

function isRetryRequired({
  statusCode, 
  retryStatusCodes, 
  currentRetryCount, 
  totalRetry}
 ){

  return (statusCode >= 500 || retryStatusCodes.includes(statusCode))
          && currentRetryCount < totalRetry;
}

function getTimeout(numRetries, backoff) {
  const waitTime = Math.min(backoff * (2 ** numRetries));

  // Multiply waitTime by a random number between 0 and 1.
  return Math.random() * waitTime;
}

While making an Axios request you have to make sure to add the variables in the request configurations:

const axios= require('axios');
const sendRequest= async () => {
      const requestConfig = {
             method: 'post',
             url: 'api.example.com',
             headers: { 
                'authorization': 'xxx',
              },
              data: payload,
              retryCount : 3,
              retryStatusCodes: ['408', '429'],
              backoff: 200,
              timeout: 5000
          };
      const response = await axios(requestConfig);
      return response.data;
}

When configuring the retry mechanism, it is important to tune the total retries, and maximum delay together. The goal is to tailor these values keeping in mind the worst-case response time to our consumers.

Pictorially this is how it will work:

For Java based applications, the same can be done using resilience4j

Conclusion

In this post, we looked at one of the many service reliability mechanisms: Retries. We saw how it works, how to configure it and tackle some of the common problems with retries using backoff and jitter.

I hope you found it helpful. Comments or corrections are always welcome.

GitHub Link for the above source code can be found here

How to Choose The Right Database for Your Application

Apoorv Tyagi — Sun, 15 May 2022 11:57:02 +0000

Introduction

Choosing which database to use is one of the most important decisions you can make when starting working on a new app or website.

If you realize down the line that you’ve made the wrong choice, migrating to another database is very costly and sometimes more complex to do with zero downtime.

Taking time to make an informed choice of database technology upfront can be a valuable early decision for your application.

(A bonus reason for why this is important is because understanding the different DBs and their properties & which one to choose over the other is quite commonly asked in job interviews)

Each database technology has advantages and disadvantages. Cloud providers like Amazon offer various database and storage options making it harder to figure out which one is the right one.

Relational databases have been a primary data storage mechanism for a long time. Non-relational databases have existed since the 1960s but recently gained traction with popular options such as MongoDB.

In this article, we will go through the factors you should consider while choosing any database.

The language determines the database

First things first. The language or the technology you are going to use never determines the database ❌

We’ve grown accustomed to technology stacks, such as MERN (MongoDB, Express, React, Node.js) & LAMP (Linux, Apache, MySQL, PHP).

There are certain reasons why these stacks evolved. But don’t assume these are the rules. You can use a MongoDB database in your Java project. You can use MySQL in your Node.js. You might not have found as many tutorials, but it's your requirements that should determine the database type & not the language.

Understanding the Tradeoff

Let's now understand the basic tradeoffs we need to deal with while making the DB decision.

The reason that we have many database options available today is due to the CAP Theorem. CAP stands for Consistency, Availability, and Partition tolerance.

Consistency means that any read request will return the most recent write.

Availability means all (non-failing) nodes are available for queries & must respond in a reasonable amount of time.

Partition Tolerance means that the system will continue to work despite node failures.

Only two of these 3 requirements can be fulfilled at any given time. If you're building a distributed app then partition tolerance is a must. So the choice remains whether we want our database to be highly available or highly consistent.

Structure of Data

If your data needs to be structured or there is a relation between different types of data that you're going to keep and at the same time you want strict data integrity then a relational database should be a better choice for you.

For example, let's say we are making a student management application where we need to store the information of certain courses and every course needs to be taken by one or more students. In this case, we can create 2 tables (Students and Courses) where the value in the Student ID column inside the Courses table points to rows in the Students table by the value of their ID column.

Apart from this if you want your DB to be ACID compliant for example in cases when you're handling payments and transactions in your application then in that case too you should prefer the SQL based databases because the counterpart i.e the NoSQL database offers weak consistency.

ACID compliance protects the integrity of your data by defining exactly what a transaction is and how it interacts with your database. It avoids database tables from becoming out-of-sync, which is super important for financial transactions. ACID compliance guarantees the validity of transactions even in the face of errors, technology failures, disastrous events, and more.

On the other hand, if your data requirements aren’t clear or if your data is unstructured, NoSQL may be your best choice.

The data you store in a NoSQL database does not need a predefined schema. This provides much more flexibility and less upfront planning when managing your database.

A NoSQL database is a much better fit to store data like article content, social media posts, sensor data, and other types of unstructured data that won’t fit neatly into a table. NoSQL databases were built with flexibility and scalability in mind and follow the BASE consistency model, which means:

Basic Availability

This means that while the database guarantees the availability of the data, the database may fail to obtain the requested data, or the data may be in a changing or inconsistent state.

Soft state

The state of the database can be changing over time.

Eventual consistency

The database will eventually become consistent, and data will propagate everywhere at some point in the future.

The structure of your data is the most important factor in deciding whether to use a SQL or NoSQL database, so put a lot of thought into this before making a decision.

Query Patterns

The next factor to consider is how you’ll query your data. This is one of the main ways to find the best database for your use case

Do you need retrieval by a single key, or by various other parameters? Do you also need a fuzzy search on the data?

Use Non-Relational databases if you are going to fetch data by key, then all you need is a key-value store (e.g. DynamoDB).
On the other hand, if you will require to query many different fields you can choose both Relational DB (e.g.MySQL) or Document DB (e.g.MongoDB).
In case you are looking for fuzzy search query capabilities (free text search), then search engines like Elasticsearch(Which also comes under NoSQL DBs) are the best fit.
But in case your data is nicely structured and organized, it is very efficient to query your data with a SQL database.

SQL is a popular query language that has been around for over 50 years now, so it’s highly mature and well-known. It efficiently executes queries and retrieves using JOINs and edits data quickly. It’s very lightweight and declarative.

Consistency

Is strong consistency required (read after write) or eventual consistency is OK?

In case you need to read your data right after your write operation (i.e. strong consistency) then a Relational database (e.g. MySQL) is usually more suited than a Non-Relational Database (e.g.MongoDB).

Performance & Scaling

All databases' performance degrades as the amount of read/write traffic increases. This is the time when optimizations such as indexing your data and scaling your DB comes into the picture.

Performance depends on various factors but the overall performance depends to a very large degree on choosing the right implementation for your use case.

SQL and NoSQL databases scale differently, so you’ll have to think about how your data set will grow in the future.

SQL databases scale vertically, meaning you’ll need to increase the capacity of a single server (increasing CPU, RAM, or SSD) to scale your database. SQL databases were designed to maintain the integrity of the data so they are best to run on a single server, hence they’re not easy to scale.

NoSQL databases are easy to scale horizontally, which means you can add more servers as your data grows. This is an advantage that NoSQL has over SQL.

This uncomplicated horizontal scaling nature of non-relational databases makes them superior to relational databases as far as availability is concerned.

The ability of NoSQL databases to scale horizontally has to do with the lack of structure of the data. Because NoSQL requires much less structure than SQL, each stored object is pretty much self-contained. Thus objects can be easily stored on multiple servers without having to be linked. This is not the case for SQL, where each table row and column needs to be related.

This is also the issue regarding performance and where SQL falls short is scaling. As a database grows in size and numbers, RDBMS as we have seen requires solutions in vertical scaling. This however comes at a significant cost. Although many commercial RDBMS products offer horizontal scaling, these can also be very expensive and even complex to implement.

If you predict you will face such an issue, then NoSQL is to be considered, as many of them were designed specifically to tackle these scale and performance issues.

Conclusion

In this article, we went through the multiple factors you should consider while selecting the type of database. In short, SQL databases provide great benefits for transactional data whose structure doesn’t change frequently (or at all) and where data integrity is paramount. It’s also best for fast analytical queries. NoSQL databases provide more flexibility and scalability, which makes them useful for rapid or iteration development.

Here's a small summary of what all we have discussed above:

Reasons to use an SQL database

When you need ACID support
Your application requires high transactions
Data integrity is essential
You don’t anticipate a lot of changes in the schema

Reasons to use a NoSQL database

You want to store large amounts of data with no structure
You keep getting Unrelated, indeterminate, or evolving data requirements
Speed and scalability are critical
When data integrity is not your top goal and you are concerned about the availability (& eventual consistency will be good enough for your use case)

I hope this helps you understand what you need to think about when selecting your database. What additional questions do you think about while selecting a database? Let me know your thoughts in the comments.

Starting out in web development?? 💻

Checkout ▶ HTML To React: The Ultimate Guide

This ebook is a comprehensive guide that teaches you everything you need to know to be a web developer through a ton of easy-to-understand examples and proven roadmaps

It contains 👇

✅ Straight to the point explanations

✅ Simple code examples

✅ 50+ Interesting project ideas

✅ 3 Checklists of secret resources

✅ A Bonus Interview prep

You can even check out a free sample from this book

and here's the link with 60% off on the original price on the complete book set ⬇

SOLID Principles in Java

Apoorv Tyagi — Wed, 26 Jan 2022 06:14:11 +0000

In software engineering, SOLID is an acronym for 5 design principles intended to make software designs more understandable, flexible, robust, and maintainable. Adopting these practices can contribute to avoiding code smells too.

The 5 SOLID principles are:

S - The single-responsibility principle
O - The open-closed principle
L - The Liskov substitution principle
I - The interface segregation principle
D - The dependency inversion principle

Although the SOLID principles apply to any programming language, in further section I will be explaining each of them with examples written specifically in JAVA.

Single Responsibility Principle

This principle states that “a class should have only one reason to change” which means every class should have a single responsibility.

public class Vehicle {
    public void details() {}
    public double price() {}
    public void addNewVehicle() {}
}

Here the class has multiple reasons to change because the Vehicle class has three separate responsibilities: printing details, printing price, and adding a new vehicle to Database.

To achieve the goal of the single responsibility principle, we should implement a separate class that performs a single functionality only.

public class VehicleDetails {
    public void details() {}
}

public class CalculateVehiclePrice {
    public double price() {}
}

public class AddVehicle {
    public void addNewVehicle() {}
}

Open-Closed Principle

This principle states that “software entities (classes etc.) should be open for extension, but closed for modification”. This means without modifying anything in a class, it should be extendable.

Let's understand this principle with an example of a notification service

public class NotificationService{
    public void sendNotification(String medium) {
         if (medium.equals("email")) {}
    }
}

Here, if you want to introduce a new medium other than email, let's say send a notification to a mobile number then you need to modify the source code in NotificationService class.

So to overcome this you need to design your code in such a way that everyone can reuse your feature by extending it and if they need any customization they can extend the class and add their feature on top of it.

You can create a new interface like:

public interface NotificationService {
    public void sendNotification(String medium);
}

Email Notification:

public class EmailNotification implements NotificationService {
    public void sendNotification(String medium){
        // write Logic using for sending email
    }
}

Mobile Notification:

public class MobileNotification implements NotificationService {
    public void sendNotification(String medium){
        // write Logic using for sending notification via mobile
    }
}

Liskov Substitution Principle

This principle states that “derived classes must be able to substitute for their base classes”. In other words, if class A is a child of class B, then we should be able to replace B with A without interrupting the current behavior of the program.

Consider an example of a square class derived from Rectangle base class:

public class Rectangle {
    private double height;
    private double width;
    public void setHeight(double h) { height = h; }
    public void setWidht(double w) { width = w; }
}
public class Square extends Rectangle {
    public void setHeight(double h) {
        super.setHeight(h);
        super.setWidth(h);
    }
    public void setWidth(double w) {
        super.setHeight(w);
        super.setWidth(w);
    }
}

In the Rectangle class, setting width and height seems perfectly logical. However, in the square class, the SetWidth() and SetHeight() don't make sense because setting one would change the other to match it.

In this case, Square fails the Liskov substitution test because you cannot replace the Rectangle base class with its derived class Square. The Square class has extra constraints, i.e., the height and width must be the same. Therefore, substituting Rectangle with Square class may result in unexpected behavior.

Interface Segregation Principle

This principle applies to Interfaces and it is similar to the single responsibility principle. It states that “** a client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.**“.

Let's understand this by the example of a vehicle interface:

public interface Vehicle {
    public void drive();
    public void stop();
    public void refuel();
    public void openDoors();
}

Let's say we now create a Bike class using this Vehicle interface

public class Bike implements Vehicle {
    public void drive() {}
    public void stop() {}
    public void refuel() {}

    // Can not be implemented
    public void openDoors() {}
}

Since Bike doesn't have doors we can't implement the last function.

To fix this, it is recommended to break down the interfaces into small multiple, interfaces so that no class is forced to implement any interface or methods, that it does not need.

public interface Vehicle {
    public void drive();
    public void stop();
    public void refuel();
}

public interface Doors{
    public void openDoors();
}

Creating two classes - Car and Bike

public class Bike implements Vehicle {
    public void drive() {}
    public void stop() {}
    public void refuel() {}
}

public class Car implements Vehicle, Door {
    public void drive() {}
    public void stop() {}
    public void refuel() {}
    public void openDoors() {}
}

Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that "entities must depend on abstractions (abstract classes and interfaces), and not on concrete implementations (classes). Also, the high-level module must not depend on the low-level module, but both should depend on abstractions".

Suppose there is a book store that enables customers to put their favorite books on a particular shelf.

In order to implement this functionality, we create a Book class and a Shelf class. The Book class will allow users to see reviews of each book they store on the shelves. The Shelf class will let them add a book to their shelf. For example,

public class Book {
    void seeReviews() {}
}


public class Shelf {
     Book book;
     void addBook(Book book) {}
}

Everything looks fine, but as the high-level Shelf class depends on the low-level Book, the above code violates the Dependency Inversion Principle. This becomes clear when the store asks us to enable customers to add their own reviews to the shelves, too. In order to fulfill the demand, we create a new UserReview class:

public class UserReview{
     void seeReviews() {}
}

Now, we should modify the Shelf class so that it can accept User Reviews, too. However, this would clearly break the Open/Closed Principle too.

The solution is to create an abstraction layer for the lower-level classes (Book and UserReview). We’ll do so by introducing the Product interface, both classes will implement it. For example, the below code demonstrates the concept.

public interface Product {
    void seeReviews();
}

public class Book implements Product {
    public void seeReviews() {}
}

public class UserReview implements Product {
    public void seeReviews() {}
}

Now, the Shelf can reference the Product interface instead of its implementations (Book and UserReview). The refactored code also allows us to later introduce new product types (for instance, Magazine) that customers can put on their shelves, too.

public class Shelf {
    Product product;
    void addProduct(Product product) {}
    void customizeShelf() {}
}

Conclusion

In this article, you were presented with the five principles of the SOLID Code. Adhering to SOLID principles can make your project, extendable, easily modifiable, well tested, with fewer complications.

Happy coding! 💻

(If you find any doubts, updates, or corrections to improve this article, Feel free to share them in the comments) 😊

Starting out in web development?? 💻

Checkout ▶ HTML To React: The Ultimate Guide

This ebook is a comprehensive guide that teaches you everything you need to know to be a web developer through a ton of easy-to-understand examples and proven roadmaps

It contains 👇

✅ Straight to the point explanations

✅ Simple code examples

✅ 50+ Interesting project ideas

✅ 3 Checklists of secret resources

✅ A Bonus Interview prep

You can even check out a free sample from this book

and here's the link with 60% off on the original price on the complete book set ⬇

Introduction to Asynchronous Processing and Message Queues

Apoorv Tyagi — Fri, 31 Dec 2021 06:08:46 +0000

Introduction

In a client-server architecture, the client can request a job to be done from the server by sending messages between each other.

Handling this communication can increase in complexity when you begin to manage the rate at which messages are sent, the number of requests a server can handle, or the response time which the client demands.

In this blog, we'll see one way to handle this intricacy.

What is Synchronous Processing?

In synchronous processing, a client sends a request to the server and waits for the server to complete its job and send back the response before the client can resume doing any other work.

This process is often referred to as a blocking request as the client gets blocked from doing any other work until a response is received.

What is Asynchronous Processing?

Asynchronous processing is the exact opposite of synchronous processing. Here, the client doesn't wait for a response after sending a request to the server and continues doing any other work.

This process is referred to as a non-blocking request as the execution thread of the client is not blocked. This allows systems to scale as more work can be done in a given amount of time.

Synchronous vs Asynchronous Processing

Synchronous requests block the execution thread of the client, forcing them to wait for the response to come before they can perform another action. On the other hand, asynchronous requests do not block and allow for more work to be done in a given time.
Since we do not know much time the request will take, it is difficult to build responsive applications with synchronous processing. The more blocking operations, the slower system becomes. With asynchronous processing, response time is quick as the client does not have to wait on the request.
Fault tolerance of asynchronous processing is higher than that of synchronous processing, as it is easy to build a retry mechanism when a request fails.

What are Message Queues?

A message queue is a component that buffers requests from one service and broadcasts asynchronously to another service.

Here, clients are the message producers, who send request messages to the queue instead of any server. They get an acknowledgment when the message is added to the queue, which enables them to continue with their other jobs without having to wait for the server.

Servers are known as message consumers and are served these messages from the queue based on the number of requests they can serve at any given time. This continues until all the messages in the queue have been served.

The two most common messaging queues are — RabbitMQ and Kafka.

Structure of Message Queues

A message queue is primarily a broker of messages between message producers and message consumers.

Each distinct entity in the messaging queue setup (producers, consumers, and queue) has a responsibility and they're decoupled from each other as much as possible.

The only contract between all entities is the messages for which the message queue facilitates the movement from producers to consumers.

In the following sections, we will discuss the responsibilities of each component and look at the various modes with which the message queue delivers a message to consumers.

Message Producers

Message producers initiate the asynchronous processing request. Producers have a responsibility to generate a valid message and publish it to the message queue. Messages submitted to the queue are then queued up and delivered to consumers to be processed asynchronously.

Producers communicate with message queues using the Advanced Message Queuing Protocol (AMQP).

Message Brokers

A message broker is simply just a queue. You can even implement a simple broker programmatically that buffers messages and sends them to consumers as and when needed.

Message brokers are the actual decoupling elements in the setup, sitting between and managing the process of communication between producers and consumers.

Because of their simplicity, brokers are optimized for high concurrency and throughput.

It is important to note that adding message brokers introduces an extra layer of complexity into your infrastructure and requires you to scale them as well. Brokers also have specific requirements and limitations when it comes to scalability.

Message Consumers

The main responsibility of consumers is to receive and process messages from the queue.

Most consumers are API services that perform that actual asynchronous processing.

Consumers can be implemented in different application languages or technologies and maintained independently from other components.

To achieve decoupling, consumers should know nothing about the producers. The only contract that should exist between the two is valid messages from the queue.

When properly decoupled, consumers can serve as independent service layers that can be used by both the message queue setup and other components in your infrastructure.

Consumer Communication Strategies

Message queues need to transmit messages down to consumers, depending on how application developers implement consumers, message queues have three distinct ways of delivering messages to the consumers:

Pull Model

In this model, the consumer periodically checks the status of the queue. This is done at a scheduled interval programmed on the side of the consumer.

If there are messages found in the queue, the consumer picks them up until there are no more messages left to process, or when the 'N' number of messages has been consumed. This 'N' can be configured on the message broker.

Push Model

Once a message is added, the consumer is notified and the message is then pushed down to it. Messages are pushed down to consumers at a rate at which the consumer can easily regulate.

Subscription Model

In this model, consumers can subscribe to a topic. This publisher publishes a message to a topic rather than a queue. Each consumer connected to the broker maintains its private queue to receive messages from topics.

After the consumers subscribe to the topics and when a message is published to that topic, the message is cloned for each subscriber and added to the consumer’s private queue.

Comparing Different Message Brokers

As we have seen above, for asynchronous communication we usually need a message broker.

Below are the few considerations you have to look at when choosing a broker for managing your asynchronous operations:

Scale: The number of messages sent per second in the system
Data Persistency: The capability to recover messages
Consumer Capability: The capability to manage one-to-one / one-to-many consumers

RabbitMQ

Scale: Based on configuration and resources.
Persistency: Both persistent and transient messages are supported.
One-to-one vs One-to-many consumers: Both.

RabbitMQ supports all major languages, including Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift, and more.

Kafka

Scale: Can send up to a million messages per second.
Persistency: Yes.
One-to-one vs One-to-many consumers: Only one-to-many

Kafka has managed SaaS on both Azure and AWS. Kafka also supports all major languages, including Python, Java, C/C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift, and more.

Redis

Scale: Can send up to a million messages per second.
Persistency: Not supported (it’s an in-memory database).
One-to-one vs One-to-many consumers: Both.

Redis is a bit different from the other message brokers. Redis is an in-memory data store. Originally, Redis only supported one-to-one communication with consumers. However, since Redis 5.0 introduced the pub-sub, you can have one-to-many as another option.

Conclusion

In this blog, we covered how asynchronous processing is advantageous over its counterparts and how a message queue helps us achieve asynchronous processing along with keeping the different entities in its setup decoupled from each other.

We also covered some basic characteristics of the most commonly used message brokers: Redis, Kafka, and RabbitMQ.

Here's a bit more detailed instruction for selecting the right message broker to use according to different use cases:

Short-lived Messages: Redis

Redis is good for short-lived messages where persistence isn’t required.

Large Amounts of Data: Kafka

Kafka is good for storing a large amount of data for long periods. Kafka is also ideal for one-to-many use cases where persistency is required.

Complex Routing: RabbitMQ

RabbitMQ is good for complex routing communication.

Happy coding! 💻

(If you find any doubts, updates, or corrections to improve this article, Feel free to share them in the comments) 😊

Starting out in web development?? 💻

Checkout ▶ HTML To React: The Ultimate Guide

This ebook is a comprehensive guide that teaches you everything you need to know to be a web developer through a ton of easy-to-understand examples and proven roadmaps

It contains 👇

✅ Straight to the point explanations

✅ Simple code examples

✅ 50+ Interesting project ideas

✅ 3 Checklists of secret resources

✅ A Bonus Interview prep

You can even check out a free sample from this book

and here's the link with 60% off on the original price on the complete book set ⬇

Building Your Online Presence

Apoorv Tyagi — Sun, 10 Oct 2021 15:23:36 +0000

Back in October 2020 I realized the importance of having an online presence when I saw this tweet on Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1317296660700016640-379'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1317296660700016640&theme=dark" }

It was really astounding to me when I learned that Daniel Vassallo has made over $250,000 just by selling couple of his courses on Gumroad and more importantly by leveraging social media.

It turns out that you can in fact replace your 9-5 job salary if you effectively use Twitter or any social media application for that matter as a marketing channel for your products.

As a software developer, we spend so much of our time writing tech blogs, created websites and apps, building SAAS products, making YouTube videos, so why don't we monetize our side hustle?

Having an online presence can definitely help us with that, it can provide you numerous of opportunities. It can give you the freedom to control your time.

Controlling your time is the highest dividend money pays - "The Psychology of Money"

In this article I'll share some of the points that I have learned in last one year that you need to focus on to get started.

Can't you succeed without having online presence?

You definitely can. I wanted to make this thing clear before moving on. There are various ways of making money on the internet these days.

But the problem is just having a profile, blog, product or YouTube channel might not be enough for you. Sure you can have great content and people might discover it on their own and it becomes a hit, but the probability of this happening is less when everyone is surrounded with what I call the "Internet noise". Your have to stand apart & to achieve it, one of the good ways is to build your credibility on the internet.

You need to have a group of people who consume the content you're producing. You need subscribers to watch the videos you're creating, you need audience to read the articles you're writing. You need clients to get freelancing gigs.

A strong online presence allows you to build your brand and credibility that you need to attract more consumers for your work. It provides a way for people to find your work easily. You don't want to have a killer product that provides so much value but you struggle to sell it.

I started being active on twitter since July last year and I was tweeting about various topics related to software engineering. Seeing my work, many people have started to DM me on twitter offering freelance jobs just because I was providing value and they liked what I was posting.

Even though I was not selling anything(except tweeting about my blogs) or trying to find a job, opportunities started coming my way. This is the power of building your credibility.

To sell your content you should have true fans. A true fan is someone who is always ready to buy anything you create just because you've given them so much value from your work for free in the past.

Think of this as an example, Imagine you have 100 true fans. If you create a product which provides 500$ - 1000$ worth of value per year, you can make 50k $ - 100k $ per year by selling it to your true fans. True fans also spread the word about your products voluntarily and there is no bigger marketing than word of mouth from your existing customers itself.

In the beginning, do not worry about true fans in the beginning. Just focus on providing value to your audience. You'll eventually see them coming your way!

Tips to Build An Online Presence

Honestly, building an online presence is very time consuming process and takes lot of effort, hard work and consistency.

You need to build credibility by providing value through your content. You'll have to consistently post quality content and interact with others' content as well.

Here are few tips that will help you get started:

Pick a social media channel depending on the type of content you want to create. YouTube, Twitter, LinkedIn, Instagram etc.
Pick your niche. Topics which your love talking about, topics which you're currently exploring a lot or you're an expert at. For instance, I'm a software developer so I generally tweet about programming, algorithms etc.
Post quality content everyday. Interact with other players of your niche. Eventually big accounts will notice you and they will start interacting with your content. And that's how you start growing big. Remember, consistency is the key.
Improve your BIO. When people hoover over your name in their timeline the first thing they see is your face & bio. YOUR bio is about what you bring THEM! Write about how you're helping your followers. What will they get if they decide to follow you.
Follow big players in your niche Before you can talk you first have to listen. Follow the players who have 10x the number of followers you have. For example, if you have 100 followers follow someone who has 1k-10k followers in your niches and see what they
talk about. Follow people with high engagement. Accounts that consistently get 10+ retweets.
Comment on big players' timelines. The guys you followed in the previous step, use their base to grow yours. Whenever you follow
someone you can turn on notifications. When they tweet you get a notification. Add value to their timeline as quickly as you
can. Do this once a day per account max. This is going to be your best friend until you hit 5k followers.

Do this for several months consistently and see the response you get. Keep doing experiments along the way with respect to what kind of posts your audience likes or dislikes. Double down on the ones that you will your audience is enjoying a lot.

But there's one caveat to this experiment. Sometimes people interact with something which is very controversial but do not provide any value at all. Make sure you do not double down on such things because it can harm your reputation in long run.

The important thing is to provide value.

This topic is so big that an investment in a detailed course can help you a lot in getting started better. I have mentioned one of the good eBook that I bought and loved and can totally recommend who wants to start out (Link at the end of the article).

What Not to Do While Building Online Presence?

Initially it might get a little frustrating to keep posting content but not having anyone to see and engage with it. The truth is everyone goes through that. But believe me, if you're creating quality content, people will eventually start noticing you.

In running this long term race, many people tend to make mistakes in order to gain some traction early, some of which are:

Copying other's content and posting it as your own without giving credit to the original author.
Asking follow for follow, likes, retweets etc. Yes people do such things just to increase those follower numbers. You will get the numbers but not the true fans.
Not being consistent with posting their content. You have to grind every single day of the week
Posting lot of content without any quality.
Start selling your products, sharing links to your blogs/videos from day one. Remember that you have to give a lot first before asking for anything. These tweets might even result in loosing followers if you overdo it. Your audience decided to follow you for your valuable content, not for your advertising.

Avoid making these mistakes and be authentic with your content. The eBook I mentioned below talk about these things in detail so if you're very serious around building your own brand, you should definitely consider buying it.

Thanks for reading and all the best for your journey :)

If you're interested to learn more about building an online presence in detail, here's one eBook that I found extremely useful
(It has a good rating as well):