DEV Community: Nikhil Amin

CH-07: The Encrypted Enigma — Jai & Veeru vs. The Key of Secrets

Nikhil Amin — Sun, 08 Jun 2025 00:30:00 +0000

The digital world was no place for the careless. Every system, every login, every transaction had to be shielded, encrypted, and fortified. Jai and Veeru, the legendary duo of developers, had seen many challenges before — but today’s mission was different.

They stood before The Vault of Authentication, a cyber fortress protecting the most precious asset of modern applications: Secure Access.

“This is it, Veeru,” Jai said, adjusting his glasses. “No one gets in without the right credentials.”

“Or out, if they mess up,” Veeru added, eyeing the firewall flickering with cryptographic defenses.

Their mission was simple: Break in — but the right way.

The Challenge: Authentication vs. Authorization

As they approached the vault’s interface, a booming voice echoed:

🚨 “IDENTIFY YOURSELVES.” 🚨

Jai confidently stepped forward. “I’m Jai. That’s Veeru. We built half the code for this place.”

ACCESS DENIED.

Veeru smirked. “Classic mistake, Jai. Authentication isn’t enough. We need authorization too.”

Jai raised an eyebrow. “Authentication proves who we are. Authorization proves what we can do.”

“Exactly! Think of it like entering a stadium. Your ticket (authentication) gets you inside, but your seat number (authorization) determines where you sit.”

Jai sighed. “Alright, let’s do this properly.”

The Solution: JWT, OAuth2 & Spring Security

To gain access, they needed three powerful tools:

JWT (JSON Web Token): Their digital passport, cryptographically signed to ensure nobody could tamper with it.
OAuth2: The system that granted access without exposing passwords.
Spring Security: The guardian of the vault, validating every request before letting anyone in.

Veeru pulled out a JWT token from his pocket. “This is our key.”

Jai inspected it:

{
  "alg": "HS256",
  "typ": "JWT"
}
{
  "sub": "Jai",
  "role": "admin",
  "exp": 1717248000
}

“The server will check the signature. If it’s valid, we’re in,” Veeru said.

“Wait, what if someone steals this token?” Jai asked.

“That’s why OAuth2 comes in! It issues short-lived access tokens and refresh tokens to maintain security.”

They input the JWT into the vault’s system.

ACCESS GRANTED. ✅

The doors swung open. They had cracked the code of secure authentication!

Cliffhanger: The Man-in-the-Middle Attack!

Just as they stepped inside, the alarm blared again.

“Unauthorized access detected!”

A shadowy figure intercepted their request logs. Someone was trying to hijack their session!

“The tokens… they’ve been compromised!” Jai whispered.

Veeru clenched his fists. “We’re dealing with a Man-in-the-Middle Attack!”

📖 To be continued… 🚀

💡Key Takeaways from This Chapter

✔ Authentication ≠ Authorization: Authentication verifies who you are; authorization verifies what you can do.
✔ JWT (JSON Web Token): A self-contained token ensuring secure, tamper-proof authentication.
✔ OAuth2: A secure way to grant limited access to applications without exposing passwords.
✔ Spring Security: Provides a framework to enforce authentication and authorization at every request.

CH-06: The Echo of Events — Jai & Veeru vs. The Microservices Mayhem

Nikhil Amin — Sun, 01 Jun 2025 00:30:00 +0000

It was a peaceful morning — until it wasn’t.

Jai and Veeru had just pushed their latest update to production when alerts started flooding in.

🚨 Service Down! 🚨
🚨 Database Overload! 🚨
🚨 API Latency Spike! 🚨

Veeru panicked. “What the hell is happening?! We just deployed a small feature!”

Jai grabbed his coffee. “Looks like we triggered a microservices meltdown…”

Their system, which relied on REST APIs for communication, was now buckling under high traffic. The database was overwhelmed with requests, leading to timeouts, bottlenecks, and service failures.

Veeru groaned. “Jai… is this how big tech companies handle millions of users?”

Jai smirked. “Not even close. It’s time to introduce you to event-driven microservices.”

The Problem: REST-Based Microservices Can’t Handle Scale

Veeru scratched his head. “But we already have a microservices architecture. Why is it failing?”

Jai explained, _“Our services communicate synchronously using REST APIs. But what happens when:

✅ Traffic surges?
✅ A service fails?
✅ Requests pile up faster than they can be processed?”

Veeru nodded. “It creates a domino effect, slowing everything down!”_

Jai pulled up a diagram.

🛑 Current REST-Based Flow:

1️⃣ User sends a request to Service A.
2️⃣ Service A calls Service B synchronously.
3️⃣ Service B queries the database, which is already overloaded.
4️⃣ Response takes too long → User faces a timeout.

“This,” Jai said, pointing to the mess on the screen, “is why big tech companies don’t rely on REST for everything.”

Veeru sighed. “So, what’s the solution?”

Jai grinned. “We decouple services using Apache Kafka.”

The Fix: Event-Driven Microservices with Kafka

Solution: Replacing REST Calls with Kafka Events

With Kafka, instead of services waiting on each other, they communicate asynchronously using an event-driven approach.

How It Works:

✅ Service A publishes an event to Kafka (instead of calling Service B directly).
✅ Kafka stores and streams the event to subscribers (Service B, C, etc.).
✅ Service B processes the event when it’s ready, not when forced.

Veeru’s eyes lit up. “That means no blocking and no direct dependencies!”

Jai nodded. “Exactly! Now, if a service crashes, the events stay in Kafka until it recovers. No data loss!”

Implementing Kafka in Spring Boot

Jai opened his code editor. “Let’s convert our system to event-driven microservices.”

Step 1: Add Kafka Dependencies

<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
    <version>3.0.0</version>
</dependency>

Step 2: Create a Kafka Producer (Publishing Events)

@Service
public class OrderEventProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public OrderEventProducer(KafkaTemplate<String, String> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void sendOrderEvent(String orderId) {
        kafkaTemplate.send("order-events", orderId);
    }
}

Step 3: Create a Kafka Consumer (Processing Events)

@Service
public class OrderEventConsumer {

    @KafkaListener(topics = "order-events", groupId = "order-group")
    public void consume(String orderId) {
        System.out.println("Processing order: " + orderId);
    }
}

Veeru whistled. “That’s it? No more synchronous API calls?”

Jai grinned. “Nope. Now our services talk to each other through Kafka. No more timeouts, database overload, or cascading failures.”

The Transformation: Before vs. After Kafka

BEFORE (REST-Based Microservices):

⏳ Services block while waiting for responses.
⚠️ If one service fails, the whole chain collapses.
📈 High traffic = database overload = system failure.

AFTER (Event-Driven with Kafka):

⚡ Services communicate asynchronously.
✅ Failures don’t break the whole system.
📊 System auto-scales with high traffic.

The Mystery Deepens…

Just as they were about to celebrate, another alert popped up.

🚨 Unauthorized Kafka Topic Detected: “shadow-events” 🚨

Veeru’s stomach dropped. “Jai… did we create that topic?”

Jai quickly checked the logs. Unknown events were flowing through Kafka — events that neither of them had written.

Veeru gulped. “Could someone be injecting rogue events into our system?”

Jai’s expression darkened. “Or worse… have we just uncovered a Kafka security breach?”

📖 To be continued… 🚀

💡Key Takeaways from This Chapter

✔ Microservices should be decoupled — REST isn’t scalable for high-traffic systems.
✔ Use Apache Kafka — It enables asynchronous event-driven communication.
✔ Event Streams Reduce Failures — If a service crashes, Kafka retains the event for processing later
✔ Spring Boot + Kafka = Scalable Microservices — Build resilient architectures that handle millions of users.

CH-05: The Lost Code — Jai & Veeru vs. The Ghost in the Repository

Nikhil Amin — Sun, 25 May 2025 00:30:00 +0000

Jai and Veeru were working late at night in their dimly lit office. The coffee cups were piling up, and Veeru was staring at his laptop screen, confused and frustrated.

“Jai, something weird is happening!” he groaned.

Jai, half-asleep, barely looked up. “Is it your buggy code again?”

Veeru shook his head. “No! Our app is supposed to log user activity, but somehow… data keeps disappearing!”

Jai frowned. “What do you mean? Logs don’t just vanish!”

Veeru pointed at the screen. “Look! Here’s a log of a user logging in… but when the request reaches the backend, poof! The data is gone!”

Jai’s eyes widened. This wasn’t just a bug. This was a ghost in the repository.

The Problem: Lost Data in Multi-Threaded Requests

Veeru’s code was using ThreadLocal to store temporary data for each request:

private static final ThreadLocal<User> currentUser = new ThreadLocal<>();

public void handleRequest(User user) {
    currentUser.set(user);
    process();
}

public void process() {
    System.out.println("Processing user: " + currentUser.get().name());
}

At first, it worked fine. But when the system scaled up and multiple requests came in, logs showed missing user data!

Veeru scratched his head. “Why is this happening, Jai?”

Jai sighed. “Because ThreadLocal is broken in virtual threads!”

The Fix: Java 21’s Scoped Values

“Veeru, let me introduce you to Scoped Values — the modern replacement for ThreadLocal!” Jai said, rewriting the code.

private static final ScopedValue<User> currentUser = ScopedValue.newInstance();

public void handleRequest(User user) {
    ScopedValue.where(currentUser, user).run(() -> process());
}

public void process() {
    System.out.println("Processing user: " + currentUser.get().name());
}

Veeru’s jaw dropped. “Wait… so Scoped Values don’t break in Virtual Threads?”

Jai nodded. “Exactly! They are immutable, memory-efficient, and safe for concurrency. No more lost data!”

The Repository’s Dark Secret

Just as Jai and Veeru were celebrating their victory, an alert flashed on the screen.

“Unauthorized commit detected. Unknown changes pushed to the repository.”

Veeru gulped. “Jai… did you push any code?”

Jai shook his head. “No… and we’re the only ones with access!”

They checked the repository logs. A mysterious commit had overwritten part of their code — the same part handling user logs!

Jai narrowed his eyes and whispered, “Could it be… a supply chain attack?”

Veeru’s face turned pale. “You mean like the Log4j exploit?”

Jai nodded. “Exactly. If someone injected malicious code into our dependencies, we might have a security vulnerability in our system right now!”

Veeru’s hands trembled as he reached for his keyboard. “Jai, we need to check our dependencies and Maven repositories — right now!”

📖 To be continued… 🚀

💡Key Takeaways from This Chapter

✔ ThreadLocal is outdated — Switch to Scoped Values for better concurrency.
✔ Scoped Values — Immutable, thread-safe, and designed for modern Java applications.
✔ Data Consistency — Ensure no data is lost in multi-threaded environments.
✔ Supply Chain Attacks — Stay updated with security best practices in Java.

CH-04 : The Singleton Paradox — Jai & Veeru vs. The Multiverse of Objects

Nikhil Amin — Sun, 18 May 2025 00:30:00 +0000

Jai and Veeru were sipping chai on their terrace when Veeru suddenly blurted out, “Jai, our app has a problem!”

Jai, halfway through a biscuit, raised an eyebrow. “What now? Did you time-travel and forget your phone again?”

Veeru shook his head. “Worse. Our app is creating too many objects! The memory usage is skyrocketing!”

Jai sighed. “Ah, the Singleton problem. We need only one instance of an object, but Java keeps making more, wasting resources.”

Veeru scratched his head. “So how do we fix it?”

Jai leaned forward, a mischievous smile forming. “We use Java 21’s Record Patterns & Sealed Classes!”

Veeru blinked. “Sounds fancy. Explain.”

The Problem: Too Many Instances

Veeru had written this code for a Logger class:

public class Logger {
    public Logger() { System.out.println("New Logger Created!"); }
}

And every time he called new Logger(), it created a new instance!

Veeru frowned. “But I only need one logger. Not a thousand!”

Jai smirked. “That’s where Singleton Pattern comes in!”

The Fix: Singleton with Sealed Classes

Jai rewrote the Logger class using Java 21’s Sealed Classes:

public sealed class Logger permits OnlyOne {
    private Logger() {} // Private Constructor  
    private static final Logger instance = new Logger();
    public static Logger getInstance() { return instance; }
}

final class OnlyOne extends Logger {} // Prevents more instances

Veeru’s eyes widened. “Wait… so now, even if someone tries to extend Logger, Java won’t allow it?"

Jai nodded. “Yes! Sealed classes restrict inheritance, enforcing one true instance!"

Veeru clapped his hands. “Jai, you’re a genius!”

Record Patterns: The New Magic Trick

Veeru frowned again. “Okay, Singleton is solved. But what if we have too many duplicate objects, like users logging in with the same details?”

Jai chuckled. “That’s where Record Patterns help. Instead of manually checking fields, Java 21 does it for us!”

Instead of writing this old, tedious way:

record User(String name, String role) {}

User u = new User("Veeru", "Admin");
if (u.name().equals("Veeru") && u.role().equals("Admin")) {
    System.out.println("Welcome, Admin!");
}

Jai showed the modern approach:

record User(String name, String role) {}

static void checkUser(User u) {
    if (u instanceof User("Veeru", "Admin")) {
        System.out.println("Welcome, Admin!");
    }
}

Veeru was stunned. “That’s so much cleaner! No more repetitive .equals() calls?"

Jai grinned. “Yup! Java 21 makes code smarter and easier to read.”

The Real Paradox…

Just as Jai and Veeru were celebrating their victory, Veeru’s phone beeped. It was an error message from their server.

“Warning: Multiple instances detected. Memory overload imminent!”

Veeru gulped. “Jai… didn’t we just fix this?”

Jai stared at the screen, confused. “Yes… which means something — or someone — is breaking the Singleton rule…”

They exchanged a nervous glance.

“Could it be… a rogue object?” Veeru whispered.

Jai’s eyes narrowed. “Only one way to find out.”

📖 To be continued… 🚀

💡Key Takeaways from This Chapter

✔ Sealed Classes — Prevent unnecessary object creation.
✔ Singleton with Permits — Restrict inheritance for a true singleton pattern.
✔ Record Patterns — Cleaner, more readable pattern matching.
✔ Better Performance — Java 21 optimizes memory and CPU usage.

CH-03 : The Phantom Thread – Jai & Veeru vs. The Virtual Thread Mystery

Nikhil Amin — Sun, 11 May 2025 00:30:00 +0000

Jai and Veeru were back in action. This time, they were working on a high-performance chat application that needed to handle thousands of users simultaneously.

“Veeru, this app must handle millions of messages per second!” Jai declared, typing away furiously.

Veeru, munching on a samosa, shrugged. “So what? We’ll just spawn thousands of threads like we always do!”

Jai’s fingers froze. He turned slowly. “Did you just say… thousands of threads?”

Veeru grinned. “Yes! More threads, more power, right?”

Jai sighed and pointed at his laptop screen. “No, Veeru. Traditional threads in Java use OS threads, which are heavy. Too many of them will make our app slow, increasing memory usage and causing thread starvation.”

Veeru looked confused. “So… what do we do? Reduce the threads?”

Jai smirked. “Nope. We use Virtual Threads!”

Enter Java 21’s Virtual Threads

Jai quickly replaced this old, heavy thread creation method:

ExecutorService executor = Executors.newFixedThreadPool(100); // Heavy OS threads  
executor.submit(() -> { 
    System.out.println("Processing request...");
});

With this lightweight Virtual Thread approach:

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {  
    executor.submit(() -> System.out.println("Processing request..."));
}

Veeru’s jaw dropped. “Wait… this creates thousands of threads without slowing down the system?”

Jai nodded. “Yes! Virtual Threads are cheap, don’t block OS threads, and allow high scalability with minimal memory usage.”

Veeru clapped his hands. “Jai, you’re a genius! This means we can handle millions of users without breaking our app!”

Structured Concurrency — Fixing Messy Thread Management

“But wait, Jai,” Veeru frowned. “Managing threads is always a headache. What if some threads finish early and others take forever?”

Jai grinned. “Good question! Java 21 solves this with Structured Concurrency. Instead of tracking and managing each thread manually, we can group tasks together!”

Instead of this traditional, messy thread management:

ExecutorService executor = Executors.newFixedThreadPool(10);  
Future<String> future1 = executor.submit(() -> fetchData("user1"));  
Future<String> future2 = executor.submit(() -> fetchData("user2"));  
System.out.println(future1.get() + future2.get());

Jai showed Veeru this cleaner, structured concurrency approach:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {  
    var user1 = scope.fork(() -> fetchData("user1"));  
    var user2 = scope.fork(() -> fetchData("user2"));  
    scope.join();  
    System.out.println(user1.get() + user2.get());  
}

Veeru was impressed. “So now, if one thread fails, we can shut everything down safely, avoiding half-executed tasks?”

Jai nodded. “Exactly! No more thread leaks or orphaned tasks.”

The Future of High-Performance Java Apps

With Java 21’s Virtual Threads & Structured Concurrency, Jai and Veeru’s chat app became:

✅ Ultra-fast — Thousands of lightweight threads without crashing the system.
✅ Memory-efficient — No wasted resources on heavyweight OS threads.
✅ Clean & Manageable — Threads were grouped logically, preventing errors.

Veeru stretched his arms. “Jai, this Java 21 update is better than a Bollywood plot twist!”

Jai laughed. “Yes, my friend! Now, let’s launch our app — this time, without a thread crisis!”

📖 To be continued… 🚀

💡Key Takeaways from This Chapter

✔ Virtual Threads — Lightweight, scalable, and perfect for high-performance apps.
✔ Structured Concurrency — Simplifies thread management, prevents failures.
✔ Goodbye Heavy OS Threads — More efficiency, fewer headaches!

CH-02 : The Time Traveler’s Bug

Nikhil Amin — Sun, 04 May 2025 00:30:00 +0000

Jai leaned back in his chair, a smug grin on his face. “Veeru, my friend, we’ve done it! The world’s first time-traveling app!”

Veeru, sipping his chai, raised an eyebrow. “You sure this works? Last time, we ended up in 1975, and Gabbar stole my phone!”

Jai rolled his eyes. “Relax. I’ve fixed all the bugs. Look, we just enter a date, and — “ He typed “March 30, 2025, 10:00 AM IST” into the console and pressed enter.

Poof! The screen flickered. The app showed March 29, 2025, 11:30 PM.

Veeru choked on his chai. “Eh? That’s yesterday! What kind of time travel is this?!”

Jai’s confidence crumbled. He scanned the code, mumbling, “Must be a daylight saving issue… Oh no.” His face turned pale. “I used java.util.Date and SimpleDateFormat. The old Java date-time APIs!"

Veeru blinked. “So?”

Jai sighed. “They don’t handle time zones properly! The app defaulted to UTC, ignoring IST.”

Veeru scratched his head. “So, how do we fix it?”

Jai cracked his knuckles. “We use java.time! The modern API makes it easy."

He replaced:

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date date = sdf.parse("2025-03-30 10:00:00");

With:

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
ZonedDateTime dateTime = LocalDateTime.parse("2025-03-30 10:00:00", formatter)
                           .atZone(ZoneId.of("Asia/Kolkata"));

Jai hit run. This time, the app correctly displayed March 30, 2025, 10:00 AM IST.

Veeru cheered. “Now that’s time travel!”

Jai smirked. “Lesson learned: Never mess with old Java date APIs. java.time is the future!"

Veeru chuckled. “Good. Now, let’s set it to 1975 again — I have unfinished business with Gabbar!”

📖 To be continued… 🚀

💡 Key Takeaways from This Chapter

✔ java.util.Date & SimpleDateFormat have time zone issues.
✔ Use java.time (LocalDateTime, ZonedDateTime) for correct time handling.
✔ Always specify a **ZoneId **when working with date and time in Java.

CH-01 : The Tale of Two Threads

Nikhil Amin — Sun, 27 Apr 2025 00:30:00 +0000

The Beginning of a Great Project

Jai and Veeru had been best friends since childhood. They had built sandcastles together, cracked math puzzles in school, and now, as software engineers, they were working on their most ambitious project yet: a personal finance tracking application.

The plan was simple — Jai would handle the data processing and calculations, while Veeru would work on fetching and updating user transactions. They were confident, excited, and ready to conquer the tech world.

But soon, chaos ensued.

The Race Condition Catastrophe

It all started on a quiet Monday morning. Jai was deep in his code, running a loop to sum up the user’s total expenses. At the same time, Veeru, unaware of Jai’s calculations, updated the transaction list in real-time.

And just like that… their program crashed.

“Jai! What did you do? My updates aren’t reflecting properly!” Veeru frowned.

“What did I do? You just modified the data while I was still processing it!” Jai shot back.

“But… we’re working together, right?”

“Yeah, but not like this! It’s like trying to count sheep while someone keeps adding more in the middle!”

Jai pulled out his laptop and ran their latest test:

class SharedAccount {
    int balance = 0;

    void addExpense(int amount) {  
        balance += amount;  
    }
}

public class RaceConditionDemo {
    public static void main(String[] args) {
        SharedAccount account = new SharedAccount();

        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) account.addExpense(10);
        });

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) account.addExpense(10);
        });

        t1.start();
        t2.start();

        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("Final Balance: " + account.balance);
    }
}

Veeru stared at the output. Instead of 20,000, they were getting random values — sometimes 18,920, sometimes 19,570.

“Wait, what? The final balance isn’t consistent?”

“Exactly,” Jai said, “because both of us are modifying the same data at the same time without control. This is a race condition.”

“Okay, so how do we fix it?”

Jai smirked. “Time to introduce some order.”

The Synchronization Spell — Preventing the Clash

Jai took a deep breath. “We need to synchronize access to the shared resource so only one thread can modify the balance at a time.”

class SharedAccount {
    int balance = 0;

    synchronized void addExpense(int amount) { // Lock applied!
        balance += amount;
    }
}

Veeru watched as Jai ran the updated code. Now, the final balance was always 20,000.

“Whoa, so synchronized makes sure that only one of us works on the balance at a time!" Veeru said, amazed.

“Exactly! It’s like locking the door while you’re in the room. I can’t come in and mess things up until you’re done.”

“But wait… doesn’t this slow things down? If one of us is waiting, the other can’t do anything!”

Jai nodded. “You’re catching on fast! That’s called thread blocking. Synchronization solves one problem but introduces another — performance bottlenecks.”

Veeru frowned. “So what do we do?”

Jai grinned. “We call the Executor.”

The ExecutorService — The Manager of Chaos

Jai leaned forward. “Instead of manually handling threads, we can use ExecutorService — think of it as a manager who assigns work to available workers efficiently.”

He wrote down the improved version:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

class SharedAccount {
    int balance = 0;

    synchronized void addExpense(int amount) {
        balance += amount;
    }
}

public class ExecutorServiceDemo {
    public static void main(String[] args) {
        SharedAccount account = new SharedAccount();
        ExecutorService executor = Executors.newFixedThreadPool(2);

        for (int i = 0; i < 1000; i++) {
            executor.submit(() -> account.addExpense(10));
        }

        executor.shutdown();
        while (!executor.isTerminated()) {}

        System.out.println("Final Balance: " + account.balance);
    }
}

Veeru’s eyes widened. “So instead of us working on our own and messing things up, we now have a manager who keeps everything running smoothly?”

Jai nodded. “Exactly. ExecutorService creates a pool of threads and reuses them efficiently instead of making new ones each time.”

Veeru grinned. “Okay, I love this! But… can we do even better?”

Jai smirked. “Of course. Let’s make it asynchronous.”

CompletableFuture — The Magic of Parallel Execution

Jai typed rapidly. “With CompletableFuture, we can run tasks in parallel, wait for them to finish, and even chain them together!"

import java.util.concurrent.CompletableFuture;

public class CompletableFutureDemo {
    public static void main(String[] args) {
        CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
            System.out.println("Fetching transactions...");
        });

        CompletableFuture<Void> task2 = CompletableFuture.runAsync(() -> {
            System.out.println("Calculating expenses...");
        });

        task1.thenRun(task2).join();
        System.out.println("All tasks completed!");
    }
}

Veeru gasped. “This is amazing! It’s like we’re both working in parallel, without blocking each other!”

Jai nodded. “That’s the power of asynchronous programming. Tasks run independently, but we can still control their flow.”

Veeru grinned. “So, first we learned synchronization to fix conflicts, then ExecutorService to manage work, and finally CompletableFuture for full parallelism!”

Jai stretched his arms. “Exactly. And that, my friend, is how you handle multithreading and concurrency in Java.”

Veeru smiled. Their project was finally working smoothly.

But little did they know… the next challenge was lurking right around the corner — Deadlocks.

📖 To be continued… 🚀

💡 Key Takeaways from This Chapter

✔ Race Conditions occur when multiple threads access shared data simultaneously.
✔ Synchronized methods prevent interference but may cause performance issues.
✔ ExecutorService efficiently manages threads and prevents overuse.
✔ CompletableFuture allows truly asynchronous execution, making programs faster.