Forem: Mihir Verma

Inside Event-Driven Architecture

Mihir Verma — Mon, 06 Apr 2026 14:35:43 +0000

When building modern distributed backend systems especially microservices, one of the most critical design decisions you will make is how those services talk to each other. If services are too tightly coupled, your entire platform becomes fragile.

This communication between services is known as service interaction. Broadly speaking, interactions fall into two categories: synchronous (waiting for a the response) and asynchronous (firing a call and moving on).

In this blog, we’ll explore:

Different types of service interactions.
Dive into Event-Driven Architecture.
Real-world patterns, use cases & types.

What is Service Interaction?

In a microservices architecture, multiple independent services collaborate to power an application. The communication between them is called service interaction, and it can be broadly classified into 3 types:

Time-Driven Interaction
Request-Driven Interaction
Event-Driven Interaction

1. Time-Driven Interaction (Synchronous)

In a time driven system, actions are triggered at fixed predetermined time intervals. Think of it as cron jobs or scheduled batch processing. A service wakes up, performs its task (like generating a daily report or restoring token limits), and goes back to sleep.

For Example: Imagine you’re building an Employee Payroll Service.

Salaries are processed once every month.
The system runs a scheduled job (cron).
A salary cerdit notification is generated.

Request-Driven Interaction (Synchronous)

This is the traditional API model. When Service A needs data or functionality from Service B, it sends a direct request (typically via HTTP or gRPC). Service A then waits for a response before it can continue the further operations.Although, it is simple to implement but the tight coupling can cause some issues. For example if Service B goes down or slow, Service A will also go down with it as it is tightly coupled (dependant on service B).

For Example: Let’s say a user places an order on your ecommerce platform.

A user places an order.
The Order Service sends a request to the Payment Service to process payment.
The Order Service waits for the payment response.
Once payment is successful, it calls the Notification Service to send confirmation. Each step depends on the previous service response if one service fails whole process goes down, making it a synchronous (request-driven) flow.

Event-Driven Architecture (Asynchronous)

In an Event-Driven Architecture, services communicate by generating and reacting to events. Instead of actively calling functions or waiting on other services, a service simply broadcasts that something happened.

It's about reacting to things that happen (events), rather than directly invoking apis/function calls.
Services are decoupled, the producer service doesn't care who consumes the event or how many consumer services there are.
In EDA, components (services) are independent, meaning they can function without being directly communicating (tightly coupled) to one another.
It uses Publish-Subscribe Design Pattern under the hood to carry out the communication.

Publish Subscribe Pattern in short:

It is a messaging paradigm in which senders (publishers) send messages message broker, which then distributes the messages to any interested receivers (subscribers) who have registered an interest in receiving those messages.

For Example: Consider a weather forecast application
A Weather Service (Publisher) publishes updates like temperature or rain alerts.

The message is sent to a message broker.
Multiple services subscribe to these updates:
Forecasting Service → predicts future weather.
History Service → stores past data.
Maps Service → updates weather on maps.

Components of Event-Driven Architecture

There are majorly 5 components of an event driven architecture.

1. Events: The core unit of communication in EDA. A change in state is called an event. In an event-driven architecture, everything that happens within and to your backend system is an event for ex. a user singing up, an order created etc.. Events are emitted by sources and can encapsulate various types of information.

The User Service emits a UserRegistered event.
The event is sent to an Event Broker.
The Email Service, which is subscribed to this event, receives it.
It gets the user data and sends a welcome email to the user.
The User Service doesn’t directly call the Email Service. It simply emits an event and carries on.

2. Event Producers (Publishers): Producers are the services responsible for emitting events (carrying out actions) when specific conditions occur. They translate system actions into enumeration messages that are consumed by other services (consumers).

For Example: Imagine a food delivery system like Zomato or Swiggy.

The delivery partner’s phone continuously sends live location (coordinates) via websocket.
The Delivery Management Service receives this data.
It acts as a Producer and emits a LocationUpdated event to the event broker.

3. Event Consumers (Subscribers): Consumers listen for specific events and when a subscribed event is received by the service it triggers some internal logic based on the event.

For Example: Continuing the same food delivery system:

The Delivery Management Service publishes LocationUpdated events.
Multiple services subscribe to this event:
Tracking Service → updates live location on the user’s app
Analytics Service → analyzes delivery performance
Restaurant Service → monitors delivery progress

These services act as Consumers which are reacting to events and performing their own tasks independently.

4. Event Broker: It is a middleware service that enables multiple services to communicate with each other through a centralized service. It routes the events between services by accepting the events from the producers and delivers them to the consumers subscribed to receive them. For example: Kafka, Rabbitmq, Redis, EventBridge etc. are used as event brokers/Message Brokers.

5. Topics: Topics Are components inside an Event-Broker. Each topic hold only certain type of events only to differentiate between the events. A publisher should know which topic it should generate the event to while consumers can subscribe to a certain topic they are interested in.

For Example:

Producer sends an event to a topic.
OrderPlaced → published to topic: orders.
Broker (Kafka, RabbitMQ, etc.) stores the event under that topic.
Consumers subscribe to the topic.
Inventory Service and Notification Service both consume from orders topic.

Why Use Event Driven Architecture ? (Advantages)

Using EDA can provide you lot of advantages while building a distributed system.

Scalable Environment: Services can scale independently.
Loose Coupling: Services don’t directly depend on each other.
Real-Time Processing: Events are processed as soon as they happen.
Fault Isolation: If a consumer is down, events can be retried later from the broker.
Cross Team Collaboration: Enables different domain teams to work together.
Independent Testing: Testing is easy as services are independent.
Highly Available: Event broker system can be horizontally scaled.

Drawbacks of EDA:

No architecture is perfect. EDA also has some trade-offs of its own.

Event Ordering: Events may arrive out of order.
Event Schema Updates: Over time, the structure of events will change which can break some consumers.
Debugging: It's hard to trace end-to-end flows across asynchronous systems.
Late Event Processing

Some Real Life Applications of EDA:

Realtime Notifications.
Live Chat.
Delivery / Cab Booking Systems (Zomato/Swiggy/Uber).
Unified Logging Mechanism.
Multiplayer Games.

Event-Driven Patterns in Practice

When designing how your events carry data, there are three main architectural patterns you will encounter:

Event Notification Pattern
Event Based State Transfer
Event Sourcing

1. Event Notification Pattern: In event notification pattern, events are used to notify other microservices in the system that an interesting change has occurred. The notification event is small and concise (contains very less information of what has changed in state) as it only contains a reference to the state that was changed. If a consumer needs more details, it must make a synchronous call back to the source to fetch the data.

For Example: Imagine a user places an order on an e-commerce platform. The Order Service creates the order and publishes an OrderPlaced event.

The event is sent to the Event Broker.
Multiple services subscribe to this event.
Inventory Service → fetches order details and updates stock.
Shipping Service → fetches order details and initiates delivery.

The event only contains basic information (like orderId), and consumers fetch additional data themselves.

Example Event:

{
  "eventType": "OrderPlaced",
  "eventVersion": "1.0",
  "timestamp": "2025-07-07T14:00:32Z",
  "eventId": "b3d9f76a-18f2-4e34-a820-7d5f2e0b8212",
  "source": "order-service",
  "data": {
    "orderId": "ORD123456",
    "userId": "USR7890",
    "orderStatus":"Preparing_Order"
  }
}

2.Event Based State Transfer: In this architectural pattern events are used to propagate state changes between services in an event-driven architecture. Instead of relying on synchronous request/response patterns the state updates are directly sent inside the event information.**
For Example: Imagine a user places an order on an e-commerce platform. The Order Service creates the order and publishes an OrderPlaced event.
Unlike notification pattern, this event contains complete order details like orderId, items, quantity, shipping address etc.

Consumers do not need to call Order Service as they already have all required data.

Example Event:

{
  "eventType": "OrderPlaced",
  "eventVersion": "2.1",
  "timestamp": "2025-07-07T14:05:00Z",
  "eventId": "8fc67c8d-921c-443a-a67a-b3aefaed3384",
  "source": "order-service",
  "data": {
    "orderId": "ORD123456",
    "status": "Not_Shipped",
    "items": [
      { "productId": "P001", "quantity": 2 },
      { "productId": "P002", "quantity": 1 }
    ],
    "shippingAddress": {
      "city": "Hyderabad",
      "pincode": "000001"
    }
  }
}

3. Event Sourcing: The Event Sourcing Pattern is a way to store data by recording every change as a sequence of events, instead of just saving the latest state. Event Sourcing records every single change which is immutable. If any failure occurs in the system the it can rebuild the current state at by using these event records any point in time.

Conclusion: Event-Driven Architecture is not just a design pattern. It’s a paradigm shift in how systems think and communicate. The goal is not to eliminate synchronous communication but to use the right approach at the right place.

I Hope now you have a better understanding of the Event-Driven Architecture, it's components and types.

If you like the content please share it with your friends, colleagues, and coding buddies. Have a nice day ❤️

Inside Javascript Hoisting

Mihir Verma — Mon, 05 Dec 2022 19:48:12 +0000

As JavaScript is getting increasingly popular and extensively used, people are utilising its ability to make both server and client-side applications that are fast and use fewer resources of a machine.

In my last post, we talked about a JS engine, its Execution context, phases and how things work inside a Javascript Engine. For this Post, we will talk about the most important concept of JS which is known as “HOISTING”.

In javascript, the variable declarations and how value is assigned to that variable work differently from other programming languages.

As we have already talked about how the JS engine works in the earlier post. it will be now easy to understand the concept of hoisting

So now let’s get started with an introduction hoisting in laymen's terms.

What is Hoisting ?

“It is a mechanism inside JS due to which all variable and function declarations are moved at the top of the scope before the code is executed”.

It does not matter where the variables or functions are declared the JS engine moves all the declarations at the top of their respective scopes before the code execution phase. The assignments stay at their place.

Now you will wonder what is this scope now.
For now, consider scope as a container where your code is present.

For Example:

function container() {
  var num1 = 4; // num1 scope is limited to container function
}

In the above example, the scope of num will be limited to function (locally scoped) as it is contained inside it. If your variable or function is present at the parent level i.e not inside any function it means it is globally scoped ie. it can be accessed from anywhere (depends on how it is declared).

Types of Hoisting

There are two types of hoisting:

Variable hoisting
Function Hoisting

1. Variable Hoisting:

In variable hoisting, the variable declarations are moved on top of their scope while the process is still inside the memory creation phase.

The hoisting working differs from the way that a variable is declared. We have three ways to define a variable: let const and var.

For every variable declaration, the variable is first assigned with a default value of “undefined” before the code execution phase where the actual value is given to the variable.

var declaration:

For Example: let's consider this code snippet

console.log("before num ==> ", num);
var num = 10;
console.log("after num ==> ", num);

Here is how the JS engine will treat this code:

1. num = undefined           // memory creation phase
2. before num ==> undefined  // execution phase
3. num = 10                  // execution phase
4. after num ==> 10          // execution phase

This is how the basic var declared variables work.

In the first step, the JS engine will look for all variable and function declarations. In our case, it will find only “num1” and move it to the top of its execution context (if it is inside any function it will go to the top of that function). Memory is allocated to the variable and the value is assigned as "undefined".

point to be noted that our variable is in global space here and it is bound to the global object due to the var declaration.

After the memory creation phase code starts executing from top to bottom.
At the first line it will find console.log(“number is = ”, num); as the value of num is undefined right now it will print undefined
In the second step, the variable gets initialised with a new value i.e 10
Again it will come to the log line 4 and print after num is = 10 as it is now being assigned an actual value.

This is how var declared hoisting works. Now let's see how to let and const hoisting works.

let & const declaration:

For Example: let's consider this code snippet

console.log("before num ==> ", num);
let num = 10;
console.log("after num ==> ", num);

run this code you will get:

console.log(num);
           ^
ReferenceError: Cannot access 'num' before initialization

You are wondering Why this error came up?

The let and const variables are hoisted and assigned a value of undefined in a separate memory space & are in a Temporal Dead Zone.

They are not bound to the global object of JS instead they have their separate memory space where they are hoisted.
The JS engine knows that they exist but cannot access their value, and these are available for access only when they are initialised with a value else they are not accessible and will give a reference error.

For Example:

as you can see in the image, the var declared variable a_var is bound to the global object so it can be accessed before initialisation. While the let and const declarations: b_let and c_const are in a separate script memory phase space but they are hoisted.

Temporal Dead Zone:

So basically from the time of hoisting till the time of value initialisation the let and const variable declarations are not accessible this time period is known as the “Temporal Dead Zone”.

2. Function Hoisting:

Functions in JS can be declared in two ways

Function Declaration
Function Expressions

Function Declaration:

In JS, the function declarations are stored as it is inside the memory in the memory creation phase. So when we call the function which is declared using legacy function declaration syntax it is accessible i.e we can call it before it is initialised. This means that function declarations are hoisted.

Here you can see in the above image, I have added a breakpoint at the start of the script which means the function is not yet started executing (only the memory phase is completed) still you can clearly see inside the global object the allow function is attached. Now let's just run the whole code

here you can see that we have called the allow function just before the actual function declaration but it is still printing allowing... this shows that function declaration are also hoisted.

The difference between variable and function hoisting is just that the variables are first assigned an undefined value whereas the function is stored as a whole inside the memory.

Function Expression:

In function expression, we store the function inside a variable which is then used to call the function.

As we know variables are hoisted and assigned an undefined value in it. Unlike function declarations, function expression hoisting work like variable hoisting. The first variable holds an undefined value in the memory creation phase and then the function is assigned to that variable.

Due to this if we call the function before actually assigning it to the variable it will throw a Type Error: allow is not a function which basically means the function expressions are not hoisted.

Arrow functions work in the same way as function expressions.

Tip:

You can try all of the above-given examples in your browser by opening inspect window in the source panel.

Conclusion:

JavaScript hoisting occurs during the creation phase of the execution context that moves the variable and function declarations to the top of the script.
The JavaScript engine hoists the variables declared using the let keyword, but it doesn’t initialise them as the variables declared with the var keyword.
The JavaScript engine doesn’t hoist the function expressions and arrow functions.

I Hope now you have a better understanding of what is JS Hoisting and what its types are.

If you like the content please share it with your friends, colleagues, and coding buddies. Have a nice day ❤️

Inside Javascript Engine

Mihir Verma — Thu, 21 Jul 2022 20:28:51 +0000

As JavaScript is getting more and more popular and extensively used, people are utilising its ability to make both server and client-side applications which are fast and use fewer resources of a machine.

In this post, we will talk about the JS Engine, its Execution context its phases and how things work inside of a Javascript Engine.

Before going into the terminologies let's see why getting the deep info about the internal workings of JS is more important. If we talk about Javascript, without understanding the internal working of the javascript engine and runtime we might get output from the program which we did not expect to come. This makes javascript stand out from other languages and harder to understand for some programmers.

Now let's get started with an introduction to the Javascript Engine.

What is a Javascript Engine?

"Javascript Engine is nothing but a program that takes code written in javascript and executes it."

Internally, several steps are involved while executing the code, but here we just need to know that, the javascript engine takes high-level code, converts it into machine code, does memory allocation, and executes our program.

Currently, there are several Javascript engines out there in the internet space. but most importantly all the engines follow a standard which is known as "ECMA Script". ECMA Script tells every engine implementation how the Javascript will be executed or we can say how will it behave that's why with every engine Javascript almost works in the same way.

The most popular JS Engines are Google V8 engine, Spider Monkey, Javascript Core, Chakra etc.

Where is this Javascript Engine reside?

Now you are wondering, Ok I got the point what does JS Engine do but where is this JS engine reside? Is this engine came builtin inside my machine or is it situated somewhere else?

So here is the answer to that question. The Javascript engine is placed inside the JS runtime ( we will cover JS runtime in the next part ) and this JS Runtime is prebuilt inside our browser. So when we install any browser we will get this Javascript Engine embedded inside it and with the help of this engine, the browser can handle all the websites/web apps that use javascript.

Components of JS Engine:

Now here starts the main part of JS Engine, the JS Engine has two major components,

Memory Heap & Call Stack.

1. Memory Heap: This is the place where all the primitives i.e. functions and objects assigned memory space.

2. Call Stack: As the name suggests this is a data structure which is a stack and is maintained by the Javascript Engine to keep track of the execution flow of our javascript program. Call stack keeps an eye on execution context which we will talk about just in a bit. Whenever a function is invoked a new Execution Context is created and Javascript Engine pushes that execution context inside this stack data structure. As we know stack uses LIFO i.e. Last In First Out property so whenever an execution context finishes its execution it just gets popped out of the stack.

How code is Internally executed?

Now as we know that javascript code is executed by the JS Engine but how it is executed let's get into that.
When we execute a particular piece of code it goes inside the Javascript Engine it creates a special environment to execute the code which is known as "Execution Context".

Now the question is when exactly this execution context is created? So to understand this we need to know how many types of execution contexts are there.

So, majorly there are two types of the execution context. first is the GEC i.e. Global Execution Context and the second one is the FEC i.e. Function Execution Context.

Now, I know you might be overwhelmed with all this info but just bear with me all info will make sense in just a bit.

Global Execution Context:
The Global Execution Context is created every time whenever your script file gets loaded inside the Javascript Engine in other words whenever you try to execute a javascript file, first of all, the global execution context is created. Inside that, all of the javascript code get's executed. For every javascript file, there will be only one GEC.

Function Execution context:
As the name suggests, the function execution context is created whenever you try to call/invoke a function. As the function execution context is created separately for every function, there can be multiple FEC exist while the code is being executed.

Both the execution context GEC and FEC are similar just there is only one difference which is the time of creation.

Now, further, this execution context is divided into two parts:

Memory & Thread of Execution / Code

1. Memory: This is the place where all the primitives i.e. functions and objects assigned memory space.

2. Code: The thread of execution or we can say the Code part is the place where our program actually gets executed.

Both these parts of the execution context have their own phases to process the program.

Memory Creation Phase
Code Execution Phase

In the Memory Creation Phase, all the variables and functions get stored inside our heap i.e. memory area. All the variables and functions are allocated with memory "at once" i.e. the memory allocation starts from the top and goes till the script ends. Initially, the variables are assigned with a default value of "undefined" and the functions are stored as it is written in the code. because of this process, a concept called Hoisting takes place. also, the creation phase adds one more piece to the memory which is known as the "Lexical Environment" but we will not talk about lexical environment and hoisting here we will save it for later.

In the Code Execution Phase, The variables which have been assigned undefined earlier in the creation phase are now assigned with the actual value defined inside the program and if we talk about function if they are invoked i.e called somewhere in the program it will create its own Function Execution Context inside its parent execution context which by default is GEC i.e global execution context.

Now let's understand all things we just saw with an example of how our code gets executed. Let's say we have a function which takes a number and returns the square of the given number.

var number = 2;

function getSquare(num) {
  var answer = num * num;
  return answer;
}

var square2 = getSquare(number);
var square4 = getSquare(4);

Now as the first step Javascript Engine will create a global execution context and as we discussed earlier in this section. This execution context will be pushed inside the Call Stack to keep track of the execution flow.

Now our first phase starts ie. the “creation phase”. Here in our program, we can see there are three variables at the first level (outside any function) number, square2 and square4. All these three variables are allocated with memory in our memory space and assigned with undefined. The function getSquare() is stored as it is in our memory area.

After the memory allocation phase-2, i.e actual code execution starts line by line. As the execution starts it will encounter 1st line which is

var number = 2;

Now as the variable number is already stored inside the memory Javascript Engine will just allocate its value which is 2 to it and update inside the memory area as well.

Now, our code execution will come to the function definition but here nothing will happen because the function is already assigned memory in the creation phase. Remember the function code only gets executed only when it is invoked/called.

Now it will encounter the below line:

var square2 = getSquare(2)

Here we are invoking a function by passing an argument and storing its return value to the square2 variable.

As we are invoking the function a new Function Execution Context is created inside our Global Execution context (GEC) which has its own memory, and code execution part and also, our new execution context is pushed inside the call stack.

Now as the stack have the Last In First Out property our new execution context will start executing first.

function getSquare(num) {
  var answer = num * num;
  return answer;
}

For this new execution context, the creation phase will start. We can see here there are two variables that need memory to get stored which are answer and num. In the function execution context if we have some parameters then those parameters are also treated as variables and assigned memory just like this.

Now, after phase one again phase two i.e. the code execution phase will start.

It will encounter the first line of the function “function getSquare(num)”. The value which we have passed while invoking the function is assigned to the num so the num will be assigned 2.

Now line 2 which is var answer = num*num; will start executing. The result of num*num which is stored inside the answer

At last return statement will get executed. As all the code is executed the function execution context is popped off from the call stack and the value which we have returned is assigned to square2. Return statement tells a function execution to jump on the previous execution context so it will again start executing GEC.

Now, this same process is followed for square4 and it is assigned with 16. After execution of both the function call, our whole program ends and the global execution context is also popped off from the call stack and memory gets cleaned up.

This is how the javascript program executes under the hood.

As the Javascript Engine executes one line of code at a time that is why the javascript is "single-threaded".

Tip:

You can see all these things working live inside your browser

Conclusion:

JavaScript Engine and Execution Context is the basis for understanding many other fundamental concepts correctly.
The Execution Context (GEC and FEC), and the call stack are the processes that are carried out internally by the JS Engine to run our javascript code.

Hope now you have a better understanding of what is JS Engine and in which order a program/code run and how JavaScript Engine allocated memory to them.

If you like the content please share it with your friends, colleagues, coding-buddies.

Have a nice day