Introduction: Unraveling the “Architecture” Behind Modern Software Development

A framework is a term that is everywhere in the fast-paced world of Software development. Frameworks are the invisible architects that empower developers to create sophisticated applications with exceptional efficiency. From building dynamic web applications with Django to developing intuitive mobile apps with React Native and Flutter, frameworks enable developers to have faster development cycles, higher code quality, and easier maintenance. However, we need to understand the underlying architecture that transforms a collection of code files into a cohesive and powerful application.

This article aims to simplify the internal architecture of software frameworks by exploring three fundamental concepts of Object-Oriented Programming (OOP): Base Classes, the Factory Pattern, and the principle of Inversion of Control (IoC). We will explore how these pillars work in action, examining their structural formation and operational backbone within a modern framework that enables developers to build highly scalable, robust, and customizable applications without having to develop the core implementation from scratch.

Understanding the foundation of Frameworks Efficiency

In terms of building software applications, the Framework provides a reusable, pre-written set of code that provides a foundational structure at its core, drastically reducing the amount of time required to write boilerplate code. Let’s imagine a real-world scenario: you want to build a car, but you wouldn’t start from scratch every time, designing every nut, bolt, and piece of wiring independently. This methodology is both costly and inefficient, resulting in inconsistent quality. Instead, car manufacturers utilize a framework of established principles, well-defined processes, and standardized components to build cars more quickly and efficiently. A framework provides a clear, predefined structure, like a chassis, which defines where the engine will be placed, where the wheels will attach, how the suspension will be mounted, and where the body parts will sit. All these design decisions are foundational to the structure of a Car framework.

Similarly, the analogy to Software: A software framework provides libraries of pre-built interfaces and functions, and defines how custom code can interact with the APIs. The developer uses framework-provided functions to connect to the database or authenticate a user; you don’t have to rewrite the same implementation frequently. This is similar to a Software architecture that defines the main components and how they interact (e.g., the Model-View-Controller framework, where there is a ‘Model’ for data, a ‘View’ for display, and a ‘Controller’ to handle logic).

What makes frameworks so essential?

• Increased Productivity: A framework reduces the time required to write boilerplate code for a common problem, enabling developers to reuse that same piece of code in multiple projects.
• Improved Code Quality: A framework often implements industry-standard design patterns, well-tested components, leading to more secure and reliable applications.
• Consistency and Maintainability: A framework code is always separated from the main application and enforces a consistent structure and coding pattern across projects, making it easier to maintain the codebase over time.

The Orchestrator: Inversion of Control (IoC)

To understand the underlying architecture of a framework, it’s essential to comprehend the Inversion of Control (IoC) characteristics, which represent a fundamental transformation in the programming paradigm.

In traditional procedural programming, object creation and lifecycle management are handled by the application code, which explicitly calls library codes or utility functions to perform these tasks.

Without Inversion of Control (Traditional Approach):

Imagine you have a class PaymentProcessor that needs to log messages.

# Traditional approach - tightly coupled logging

class ConsoleLogger:
    def log(self, message: str):
        """
        Logs a message to the console.
        """
        print(f"[Console Log] {message}")

class PaymentProcessor:
    def __init__(self):
        """
        Initializes the PaymentProcessor.

        PaymentProcessor is responsible for creating its own ConsoleLogger, resulting in tight coupling.
        """
        self.logger = ConsoleLogger()

    def process_payment(self, amount: float):
        """
        Processes a payment and logs messages using the internal ConsoleLogger.
        """
        self.logger.log(f"Processing payment of {amount}")
        print(f"Payment logic for {amount} executed.")
        self.logger.log(f"Payment processed successfully for {amount}.")

# Example of usage:
if __name__ == "__main__":
    print("--- Demonstrating Traditional Approach (Tight Coupling) ---")

    processor = PaymentProcessor()
    processor.process_payment(100.00)

    print("\n--- Implications ---")
    print("Notice how 'PaymentProcessor' directly creates 'ConsoleLogger'.")
    print("If you wanted to change to a 'FileLogger', you'd have to modify 'PaymentProcessor'.")
    print("This makes testing and reusability harder.")

Problems with this approach:

1. Tight Coupling: The PaymentProcessor is tightly coupled to the ConsoleLoggerclass, and modifying the PaymentProcessor class is required to switch to a FileLogger or DatabaseLogger class.
2. Test Flexibility: With the current implementation, it’s hard to test PaymentProcessor without ConsoleLogger (or mock ConsoleLogger directly).
3. Duplication: When the other class implements logging, it instantiates the logger separately, resulting in ConsoleLoggerbeing instantiated independently of the original instance. This leads to code duplication and potential issues if the logger configuration changes.

With Inversion of Control (using Dependency Injection)

Now, let’s implement IoC using Dependency Injection, which is a common way to achieve IoC. We will introduce an ILoggerinterface and inject the specific logger implementation.

# 1. Define an interface
from abc import ABC, abstractmethod


class ILogger(ABC):
    @abstractmethod
    def log(self, message: str):
        pass


# 2. Implement different logging strategies
class ConsoleLogger(ILogger):
    def log(self, message: str):
        print(f"[Console Log] {message}")


class FileLogger(ILogger):
    def __init__(self, file_path: str):
        self.file_path = file_path

    def log(self, message: str):
        print(f"[File Log to {self.file_path}] {message}")


class DatabaseLogger(ILogger):
    def __init__(self, db_conn_string: str):
        self.db_conn_string = db_conn_string

    def log(self, message: str):
        print(f"[Database Log to {self.db_conn_string}] {message}")


# 3. Modify PaymentProcessor to accept an ILogger through its constructor
class PaymentProcessor:
    def __init__(self, logger: ILogger):
        self.logger = logger

    def process_payment(self, amount: float):
        self.logger.log(f"Processing payment of {amount}")


# 4. The "Inversion of Control" happens in the main application or a framework
class Application:
    def run(self):
        # Control is inverted, instead of PaymentProcessor creating the logger, the Application
        # decides which logger to provide to PaymentProcessor.

        print("--- Scenario 1: Using ConsoleLogger ---")
        console_logger = ConsoleLogger()
        console_payment_processor = PaymentProcessor(console_logger)
        console_payment_processor.process_payment(100.00)

        print("\n--- Scenario 2: Using FileLogger ---")
        file_logger = FileLogger("app.log")
        file_payment_processor = PaymentProcessor(file_logger)
        file_payment_processor.process_payment(250.50)


if __name__ == "__main__":
    app = Application()
    app.run()

How is Inversion of Control achieved in this scenario?

• Who creates the logger? Earlier, we saw in the traditional approach that the PaymentProcessor class creates the logger. In the IoC approach, the PaymentProcessor class doesn’t create the logger; instead, it shifts the responsibility of creating and managing the ILogger dependency from PaymentProcessor to an external entity, Application.
• Decoupling: PaymentProcessor is flexible to switch to a different logging mechanism without alteration, because it’s no longer tightly coupled to a specific logging implementation. It currently only depends on the ILogger interface.
• Testability: This improves testability for PaymentProcessor, enabling you to test in isolation. You can easily inject a mock that doesn’t write to a console or file.
• Framework Control: An IoC container handles the creation and injection of these dependencies within a framework, based on the configuration, and enables centralized control.

In summary, IoC is an orchestrator, and base classes and factories are the instruments through which orchestration is achieved. The application code doesn’t manage the core implementation, such as server management, routing, or HTTP parsing; instead, these are handled by the Framework through inverted control flow.

Base Classes: The Blueprint and the Contract

In object-oriented programming (OOP), the concept of a Base class serves as the foundation, providing a blueprint (superclass/parent class) from which other derived classes/subclasses/child classes can inherit. This mechanism provides a common interface that enables the reuse of shared attributes and methods defined in the Base class, which are used across all derived classes.

The Role and Structure of Base Classes:

• Shared Attributes and Methods: In the Base class, the defined attributes and methods are common to all derived classes.
• Abstraction: Define methods that subclasses must implement to complete a required implementation.
• Default Behaviour: It’s flexible to provide default implementations of methods that subclasses can implement as-is or override based on the requirements.

How Base Classes Serve Frameworks:

In the context of a Software Framework, the Base class is the primary class that provides its “Frozen Spots” and defines its “Hot Spots” for extensibility. These are the fundamental concepts of the Framework’s architecture and how it can be extended or customized.

• Frozen Spots: These parts of the Framework are invariant, meaning the defined core logic and core architecture remain unchanged (frozen) across applications built using the Framework. These implementation often uses concrete classes, abstract classes with invariant methods, or fixed interfaces that developers interact with but don’t change.
• Hot Spots: These are the specific areas where developers can add their application code or business logic to customize the functionality for a particular project. Developers are expected to override the defined empty methods to complete the implementation of an application, which are an abstraction of Base classes used as hooks within a Framework.

Example: A Report Generation Framework

A software application that is coded to generate various types of reports (e.g., daily reports, monthly reports, and quarterly financial reports). Each report has its unique format, but the report generation steps follow a standard format: fetching data, processing, and outputting the results.

In this scenario, a standardised framework designed to generate different reports ensures that common steps are handled consistently and allows developers to add custom logics for unique report requirements.

1. The “Frozen Spot”: BaseReportGenerator

The Framework defines an unchangeable sequence of steps common to all reports, that is the “Frozen Spot”, which is part of the framework logic that developers generally don’t modify.

from abc import ABC, abstractmethod


class BaseReportGenerator(ABC):
    """
    Abstract Base Class defining the fixed steps for report generation.
    This is the 'Frozen Spot' - the invariant algorithm.
    """

    def generate_report(self):
        """
        The Template Method (orchestrator) - this framework fixes this sequence
        """
        print(f"\n--- Generating Report: {self.__class__.__name__} ---")
        self._setup()
        data = self.fetch_data()
        processed_data = self.process_data(data)
        self.output_report(processed_data)
        self._teardown()
        print(f"--- Report Generation Complete: {self.__class__.__name__} ---\n")

    @abstractmethod
    def fetch_data(self):
        """
        Abstract method to fetch raw data for the report.
        Developer MUST implement this for specific data sources.
        """
        pass

    @abstractmethod
    def process_data(self, raw_data):
        """
        Abstract method to transform/process the raw data.
        Developer MUST implement this for specific report logic.
        """
        pass

    @abstractmethod
    def output_report(self, processed_data):
        """
        Abstract method to output the report (e.g., print, save to file, web).
        Developer MUST implement this for specific output formats.
        """
        pass

    def _setup(self):
        """
        Optional hook method for pre-processing steps.
        Provides a default empty implementation.
        """
        print(f"Setting up {self.__class__.__name__}...")

    def _teardown(self):
        """
        Optional hook method for post-processing steps.
        Provides a default empty implementation.
        """
        print(f"Tearing down {self.__class__.__name__}...")

2. The “Hot Spots”: Specific Report Implementations

These are the places where the application developer injects custom code for report-specific logic. To implement this, create a custom class that inherits from the BaseReportGenerator and implements (overrides) its abstract methods.

import datetime

class DailySalesReport(BaseReportGenerator):
    """
    Developer's implementation for a specific report.
    This fills in the 'Hot Spots' of the framework.
    """
    def fetch_data(self):
        print("Fetching daily sales data from database...")
        return [
            {"product": "Laptop", "sales": 10, "revenue": 10000},
            {"product": "Mouse", "sales": 50, "revenue": 1000},
            {"product": "Keyboard", "sales": 20, "revenue": 1500},
        ]

    def process_data(self, raw_data):
        print("Calculating total daily revenue...")
        total_revenue = sum(item['revenue'] for item in raw_data)
        return {"date": datetime.date.today(), "total_revenue": total_revenue, "details": raw_data}

    def output_report(self, processed_data):
        print("Outputting Daily Sales Report to console:")
        print(f"Report Date: {processed_data['date']}")
        print(f"Total Daily Revenue: ${processed_data['total_revenue']:.2f}")
        print("Detailed Sales:")
        for item in processed_data['details']:
            print(f"{item['product']}: {item['sales']} units, ${item['revenue']:.2f}")

    def _setup(self):
        super()._setup()
        print("(Specific setup for Daily Sales Report)")

class ProductStockReport(BaseReportGenerator):
    """
    Another developer's implementation for a different report.
    """
    def fetch_data(self):
        print("Fetching current product stock levels from inventory system...")
        return [
            {"item": "Laptop", "stock": 50},
            {"item": "Monitor", "stock": 120},
            {"item": "Webcam", "stock": 300},
        ]

    def process_data(self, raw_data):
        print("Identifying low stock items...")
        low_stock_threshold = 100
        low_stock_items = [item for item in raw_data if item['stock'] < low_stock_threshold]
        return {"total_items": len(raw_data), "low_stock": low_stock_items, "all_stock": raw_data}

    def output_report(self, processed_data):
        print("Outputting Product Stock Report to a simulated file:")
        filename = f"product_stock_report_{datetime.date.today().isoformat()}.txt"
        with open(filename, "w") as f:
            f.write(f"Product Stock Report - {datetime.date.date.today()}\n")
            f.write(f"Total Unique Items: {processed_data['total_items']}\n\n")
            f.write("Low Stock Items (below 100):\n")
            if processed_data['low_stock']:
                for item in processed_data['low_stock']:
                    f.write(f"  - {item['item']}: {item['stock']} units\n")
            else:
                f.write("No items currently low in stock.\n")
        print(f"Report saved to {filename}")

    def _setup(self):
        super()._setup()
        print("(Specific setup for Product Stock Report)")

3. The Framework IoC in Action

To generate a specific report, the Framework’s main execution loop will instantiate a particular report generator and then simply call its generate_report() method without knowing the internal details of how each report fetches, processes, or outputs data.

if __name__ == "__main__":
    print("Framework Dispatcher: Starting Report Generation Process\n")

    # The framework (or an orchestrator) decides WHEN to create and run your reports.
    # It doesn't know the specifics of sales data or stock data.

    # 1. Generate Daily Sales Report
    sales_report_instance = DailySalesReport()
    sales_report_instance.generate_report()

    # 2. Generate Product Stock Report
    stock_report_instance = ProductStockReport()
    stock_report_instance.generate_report()

    print("\nFramework Dispatcher: All Reports Generated.")

The Factory Pattern: Orchestrating Object Creation

In the previous section, we saw how the Base class defines the component structure and how it should fit into the Framework’s structure. However, the Factory Pattern addresses the crucial aspects of how these components are created, focusing on a creational design pattern that provides flexible and controlled object creation, thereby making the system independent and encapsulating the logic for object instantiation.

The factory class determines object creation because, instead of directly instantiating objects using constructors, client code interacts with the factory and common interfaces of the objects it creates.

Advantages of the Factory Pattern:

• Encapsulates Creation Logic: The object creation encapsulates the logic, and the client code doesn’t need to know the specific class name or logic required to create different types of objects.
• Decoupling: The concrete class from which the objects it creates decouple from the client code, and the client only interacts with the interface/base class of the created objects.
• Flexibility and Extensibility: Without modifying the existing client business logic, new types of objects or factory implementations can be added to the system. The addition or updation is only required for the factory’s creation logic or adding a new factory implementation.
• Polymorphic Creation: A single factory is flexible to produce various types of objects that inherit a common base or interface.

How the Factory Pattern Serves Frameworks:

The Factory Pattern serves frameworks by combining IoC and base classes.

• Dynamic Component Instantiation: The Framework’s internal architecture is often implemented to handle the dynamic instantiation of various components based on runtime conditions (e.g., routing based on the controller, user requests based on services, etc.), and the Factories implement these controlled mechanisms.
• Abstracting System Dependencies: In a large and complex framework that supports multiple underlying technologies (Such as Different database systems, caching mechanisms, and templating engines), the factory design pattern can abstract the creation of objects for these technologies.
• Plug-and-Play Architectures: If a framework enables user-defined plugins, a factory can be used to instantiate custom components at runtime, allowing users to extend the Framework’s capability seamlessly.
• Implementing IoC for Object Creation: The Framework’s internal factory is invoked, and decides which specific object to return based on the configuration. For Example, instead of the application code directly instantiating new DatabaseConnection() The Framework’s internal DatabaseFactorty() is invoked and decides which specific MySQLConneciton or PostGreSQLConnection to return based on the configuration.

Example: A Simple Framework Component “NotificationFactory”

Let’s imagine a simple framework that needs to send various types of notifications — (Email, SMS, or push notifications).

from abc import ABC, abstractmethod


# Base Class for all notification types
class Notifier(ABC):
    @abstractmethod
    def send(self, recipient, message):
        pass


# Framework provided or user-defined
class EmailNotifier(Notifier):
    def send(self, recipient, message):
        print(f"Sending email to {recipient}: {message}")


class SMSNotifier(Notifier):
    def send(self, recipient, message):
        print(f"Sending SMS to {recipient}: {message}")


class PushNotifier(Notifier):
    def send(self, recipient, message):
        print(f"Sending push notification to {recipient}: {message}")


# Framework's Factory
class NotificationFactory:
    """
    A factory responsible for creating Notifier objects.
    This hides the concrete implementation details from the client.
    """

    @staticmethod
    def get_notifier(notifier_type):
        if notifier_type == "email":
            return EmailNotifier()
        elif notifier_type == "sms":
            return SMSNotifier()
        elif notifier_type == "push":
            return PushNotifier()
        else:
            raise ValueError(f"Unknown notifier type: {notifier_type}")


# --- How a developer uses it (in their application logic) ---

class UserService:
    def __init__(self, notification_type="email"):
        # The service doesn't care about the concrete notifier class,
        # it just asks the factory for an object that can 'send' notification.
        self.notifier = NotificationFactory.get_notifier(notification_type)

    def register_user(self, username, email):
        print(f"Registering user: {username} with email: {email}")
        welcome_message = f"Welcome, {username}! Your account is created."
        self.notifier.send(email, welcome_message)


# --- Framework's (or main app's) entry point ---
if __name__ == "__main__":
    email_service = UserService("email")
    email_service.register_user("Alice", "alice@example.com")

    sms_service = UserService("sms")
    sms_service.register_user("Bob", "+914582369853")

    push_service = UserService("push")
    push_service.register_user("Tom", "charlie_device_token")

    try:
        unknown_service = UserService("fax")
        unknown_service.register_user("David", "david@example.com")
    except ValueError as e:
        print(f"Error: {e}")

In this Example:

• Notifier — The mechanism for sending notifications across all channels serves as a base class/interface.
• EmailNotifier , SMSNotifier and PushNotifier — These are the concrete class implementations.
• NotificationFactory — This is a factory class that creates the Notifier objects.
• UserService — This is the application logic and uses the Framework and asks NotificationFactory for a Notifier to send an email or SMS based on the notification type. The following demonstration shows the decoupling and the Framework’s control over object creation.

Beyond the Basics: Related Concepts

Other patterns and principles work alongside each other within a Framework, and Base Classes, Factories, and IoC work in the central area.

• Dependency Injection (DI): The Framework injects the dependencies into a class rather than the class creating them itself, a specific form of IoC that works with factories.
• Strategy Pattern: Factories create different “strategy” objects based on the configuration, allowing them to be selected at runtime.
• Observer Pattern: The Framework often uses this pattern for event handling, when one object changes its state, then all its dependents are notified and updated automatically.
• Template Method Pattern: This design pattern often directly implements the “Frozen Spots” and “Hot Spots” using inheritance. The base class defines the skeleton of an algorithm, but subclasses override specific steps of the algorithm without changing its structure.
• Architectural Patterns (MVC, MVP, MVVM): To build a framework with proper architecture, it requires implementing high-level design patterns that define the overall structure and interaction between the main components of an application. These are not code patterns but conceptual guidelines that guide how an application should be organized to promote separation of concerns, testability, and maintainability.

Conclusion: Empowering Developers Through Abstraction and Structure

In Framework, the implementations are essentially collections of utility functions, and the architectural blueprints provide developers with the flexibility to orchestrate the development process. With the power of Inversion of Control, the Framework dictates the flow. It allows developers to call defined logic at the right moments, and this is made possible by leveraging “Base Classes” & “The Factory Pattern”.

• Base Classes: It provides a foundational structure where developers inject their custom business logic in critical “Hot Spots” of common functionalities. Ensures the defined contract and custom components fit seamlessly into the Framework’s design.
• The Factory Pattern: The intelligent object creator that dynamically creates the components based on the configurations or runtime conditions, and ensures, without code modifications, that the Framework can easily accommodate new types of objects.

To design better software, the principles of modularity, decoupling, and high cohesion are essential in frameworks for building robust software systems. If you understand how the Framework operates, the flow of control helps in debugging the issue more efficiently. A deeper understanding of these underlying principles enables you to write cleaner, more idiomatic code, which in turn allows you to leverage the Framework’s capabilities as a whole.

Always remember the next time you install pip install django or npm install react Beneath the surface lies a beautifully engineered system that relies on these OOP principles, providing the robust scaffolding needed to build the next generation of incredible Software applications.

This article will discuss my recent development of Kafka Manager in Python. The tool is open-source on my GitHub and has detailed documentation. Please visit, and if you’re interested in new features and ideas, feel free to raise a PR to contribute.

Repository link: https://github.com/anshumanpattnaik/kafka-manager

Kafka’s real-time use cases are present in most applications, such as real-time data streaming, messaging systems, log aggregation, etc. This piece of technology is versatile and can serve as a robust and scalable message broker, which is often a replacement for legacy systems like RabbitMQ or ActiveMQ. Proper management techniques for producers, consumers, and topics are essential to implement Kafka within a system. I have written a Python utility class to interact with Kafka to simplify the process, providing a higher-level abstraction for managing Producers, Consumers, and Topics. The core concept of the Kafka Manager class is that it integrates the kafka-python library internally, encapsulates the complexity behind the implementation of the Kafka API, and provides a user-friendly interface for developers to implement Kafka effectively in their applications.

Why Kafka Manager class?

A Manager class is a general concept in Software development designed to control, coordinate, and oversee the lifecycle and operations of other objects or resources within an application. The manager class doesn’t necessarily perform all the tasks, but defines core functions to ensure that the proper functions do the right thing at the right time. The core responsibilities of the Manager class are to maintain the object lifecycle management to create, initialize, start, stop, and destroy instances of the objects it manages. The managed object’s resource and state management should happen properly once resource allocation is completed, and it’s the responsibility of the manager class to define functions to release shared resources, which again will be called by the parent application explicitly.

So, the main reason for building Kafka Manager as a separate library is that the kafka-python library provides many core functionalities, such as Producing Messages, Consuming Messages, Metadata Operations, and Low-Level Client operations. Implementing all these modules repeatedly in every project is redundant, and managing the implementation and complexity behind the Kafka-Python library is challenging. I decided to write a Python utility class that simplifies the Kafka interaction and provides a high-level abstraction for managing Producers, Consumers, and Topics, which will be user-friendly for developers to implement Kafka effectively in their applications. This methodology makes the code more organized, maintainable, and testable.

You can install the library with the following command:

pip install kafka-manager

I have also published documentation with all the procedures. See for more details:
https://kafka-manager-docs.readthedocs.io/en/latest/index.html

What are the Features Kafka Manager provides?

The kafka-manager library’s highlighted features help developers work with Kafka by offering a higher level of abstraction, simplifying common operations, providing control over key components of Kafka, and promoting robust and stable integrations.

1. Producer Management
2. Consumer Management
3. Topic Management
4. Admin Client Configurations
5. Error Handling
6. Resource Management

Producer Management

It provides interfaces to start/stop producers, send messages to topics, and check the producer running status. It also invokes functions to initialize and terminate producer instances to publish messages to Kafka, and it effectively checks the producer status to ensure that messages are sent successfully.

import json

from kafka_manager.kafka_manager import KafkaManager

bootstrap_servers = ['localhost:9092']  # Replace with your Kafka broker addresses
topic_name = 'example_topic'  # Replace topic name with your choice
group_id = 'example_group'  # Replace consumer group ID with your choice

# Create a KafkaManager instance
kafka_manager = KafkaManager(bootstrap_servers=bootstrap_servers)

# Start the Kafka producer
kafka_manager.start_producer();

# Send Kafka message
try:
    message_payload = json.dumps({
        "message_key": "message_value"
    })
    metadata = kafka_manager.send_message(topic=topic_name, value=message_payload)
    if metadata:
        print(f'Message sent successfully to Kafka topic: "{topic_name}"')
    else:
        print(f'Failed to send message to Kafka topic: "{topic_name}"')
except Exception as e:
    print(f'Error in sending message to Kafka topic: {e}')

# Stop Kafka producer
kafka_manager.stop_producer();

Consumer Management

It enables configuring various configurations to Create/Manage consumers and provides an interface to start/stop consumers. The Kafka Manager allows developers to create consumers per their application needs, such as different deserialization methods or offset management strategies. It provides a user-defined callback function to consume messages, allowing developers to define custom logic for processing each received message and enabling further data processing.

from kafka_manager.kafka_manager import KafkaManager

bootstrap_servers = ['localhost:9092']  # Replace with your Kafka broker addresses
topic_name = 'example_topic'  # Replace topic name with your choice
group_id = 'example_group'  # Replace consumer group ID with your choice

# Create a KafkaManager instance
kafka_manager = KafkaManager(bootstrap_servers=bootstrap_servers)

# Create a Kafka Consumer
consumer = kafka_manager.create_consumer(topics=[topic_name], group_id=group_id, auto_offset_reset='earliest')

# Start the Kafka Consumer
kafka_manager.start_consumer(consumer_id=group_id):

def message_handler(message):
    """
    This method is a callback function called by the consumer, which handles the received messages when a new message
    arrives.

    In production real-world application, the received message would be processed as follows:
    - Perform some business logic
    - Store the message in a database for further processing.
    - Message deserialization
    - etc.

    :param message: Message received from the consumer.
    """
    print(f'Received message: Partition={message.partition}, Offset={message.offset}, Value={message.value}')

# Consume Messages
kafka_manager.consume_messages(consumer_id=group_id, message_handler=message_handler)

Topic Management

Kafka-Manager allows developers to create and delete topics dynamically, which serve as categories from which sent messages are published. It’s essential for managing data streams and evolving application requirements.

from kafka_manager.kafka_manager import KafkaManager

bootstrap_servers = ['localhost:9092']  # Replace with your Kafka broker addresses
topic_name = 'example_topic'  # Replace topic name with your choice
group_id = 'example_group'  # Replace consumer group ID with your choice

# Create a KafkaManager instance
kafka_manager = KafkaManager(bootstrap_servers=bootstrap_servers)

# For topic management connect to Kafka admin client
kafka_manager.connect_admin_client()

# Create a topic - (if it doesn't exist)
kafka_manager.create_topic(topic_name=topic_name, num_partitions=1, replication_factor=1)

Admin Client Configurations

It provides interfaces to connect to the Kafka Admin client and allows developers to perform administrative operations such as creating and deleting topics. However, the admin-client connection is vital to performing many advanced Kafka management tasks, such as describing cluster configurations and managing Kafka ACLs.

from kafka_manager.kafka_manager import KafkaManager

bootstrap_servers = ['localhost:9092']  # Replace with your Kafka broker addresses
topic_name = 'example_topic'  # Replace topic name with your choice
group_id = 'example_group'  # Replace consumer group ID with your choice

# Create a KafkaManager instance
kafka_manager = KafkaManager(bootstrap_servers=bootstrap_servers)

# Connect to Kafka admin client
admin_client = kafka_manager.connect_admin_client()

# Listing Consumer Groups
consumers_groups = admin_client.list_consumer_groups()
print(consumers_groups)

# Describing Consumer Groups
admin_client.describe_consumer_groups(list(consumers_groups))

Error Handling

To handle errors in Kafka due to network failures, broker failures, or misconfigurations, Kafka Manager handles these exceptions efficiently and ensures application stability.

Resource Management

Kafka Manager resource management ensures that all connections to Kafka are correctly closed. It provides a close() function for proper shutdown, which prevents resource leaks and potential data corruption. It’s essential for maintaining data integrity and managing the Kafka cluster and application.

How to use the kafka-manager library?

The following section provides a basic example of how to use the kafka-manager library and a real implementation of its use.

import json

from kafka_manager.kafka_manager import KafkaManager

bootstrap_servers = ['localhost:9092']  # Replace with your Kafka broker addresses
topic_name = 'example_topic'  # Replace topic name with your choice
group_id = 'example_group'  # Replace consumer group ID with your choice


def message_handler(message):
    """
    This method is a callback function called by the consumer, which handles the received messages when a new message
    arrives.

    In production real-world application, the received message would be processed as follows:
    - Perform some business logic
    - Store the message in a database for further processing.
    - Message deserialization
    - etc.

    :param message: Message received from the consumer.
    """
    print(f'Received message: Partition={message.partition}, Offset={message.offset}, Value={message.value}')


def main():
    # 1. Create a KafkaManager instance
    kafka_manager = KafkaManager(bootstrap_servers=bootstrap_servers)

    # 2. For topic management connect to Kafka admin client
    if not kafka_manager.connect_admin_client():
        print('Failed to connect to Kafka admin client.')
        exit()

    # 3. Create a topic - (if it doesn't exist)
    try:
        # Define topic
        if not kafka_manager.create_topic(topic_name=topic_name, num_partitions=1, replication_factor=1):
            print(f'Failed to create topic "{topic_name}". Check that if the topic already exists.')
        # In production, please ensure the topic exists; don't exit the check and continue.
    except Exception as e:
        print(f'Error in creating Kafka topic: {e}')

    # 4. Start the Kafka producer
    if not kafka_manager.start_producer():
        print('Failed to start Kafka producer.')
        exit()

    # 5. Send Kafka message
    try:
        message_payload = json.dumps({
            "message_key": "message_value"
        })
        metadata = kafka_manager.send_message(topic=topic_name, value=message_payload)
        if metadata:
            print(f'Message sent successfully to Kafka topic: "{topic_name}"')
        else:
            print(f'Failed to send message to Kafka topic: "{topic_name}"')
    except Exception as e:
        print(f'Error in sending message to Kafka topic: {e}')

    # 6. Create a Kafka Consumer
    consumer = kafka_manager.create_consumer(topics=[topic_name], group_id=group_id, auto_offset_reset='earliest')
    if consumer is None:
        print('Failed to create consumer.')
        exit()

    # 7. Start the Kafka Consumer
    if not kafka_manager.start_consumer(consumer_id=group_id):
        print('Failed to start consumer.')
        exit()

    # 8. Consume Messages
    kafka_manager.consume_messages(consumer_id=group_id, message_handler=message_handler)

    # 9. Stop Kafka producers, Kafka consumers and Admin Client.
    kafka_manager.stop_producer()
    kafka_manager.stop_consumer(consumer_id=group_id)
    kafka_manager.close_admin_client()
    print('Stopped all Kafka producer, consumer and admin client.')


if __name__ == "__main__":
    main()

The above example is only a basic implementation of how to get started with the library. Still, you can implement it in the real world based on a suitable design pattern.

Conclusion

The current development of the library is the initial version, which shows how the library can encapsulate the complexity behind the kafka-python library and provides an interface to interact with Kafka seamlessly. Still, many more developments are in progress. Stay tuned for future updates. Please check out this repository and contribute if you’ve any new feature suggestions or encounter any issues with bug fixes.

This article provides an overview of how to get started with the library. If you have any questions or suggestions, please reach out to me on X at @anspattnaik.

Kafka is a distributed streaming platform, one of the industry’s most widely used framework. The primary use case of this platform is to build a real-time streaming data pipeline that combines messaging, storage, and stream processing to analyze historical and real-time data. This article will teach the architecture behind Kafka and its use cases.

What is Apache Kafka?

Apache Kafka is an open-source streaming data platform originally developed by LinkedIn. To further enhance the development of this project, LinkedIn donated the project to the Apache software foundation, and now the framework is being used by many companies for mission-critical projects.

Kafka is designed to handle high-throughput distributed systems that run as a cluster and can scale to handle large-scale applications and also serve as a storage system that keeps the data as long as necessary, which means it becomes a unique messaging queue from traditional message queue that removes messages immediately after the consumer reads the message. The amount of time Kafka stores the data is called retention. These retention periods are configurable, and you can set them in the log retention policy. The default value is 168 hours (seven days), after which Kafka will automatically drop the logs even if the segment is not full. Still, as I mentioned, you can change this period and set it to “forever” which will keep the log indefinitely.

Can Apache Kafka consider as a Database?

As we’ve seen, Kafka can also serve as a storage system that can replicate data over the brokers inside a cluster, but can we trade off using Kafka as a database? That depends on your requirements, but in theory, the answer is yes because there are many add-ons provided by Kafka, like ksqlDB or Tiered storage for data processing and event streaming, that you can use in your application. But many different types of databases are available, like relational databases, NoSQL, and many more. Now the question is how to choose which database is suitable for your application, either Kafka or any other traditional database system.

Trade-Offs

1. What is the structure of the data? (i.e. JSON, CSV, etc.)
2. How long does the data need to be retained in the database?
3. Do I have to run any complex aggregation queries to retrieve the data?
4. Do I require an ACID guarantee?
5. What is the volume?

These trade-offs require more analysis, and once you have found all the answers to all these questions, you can decide which database is suitable for your application. Always remember every database architecture is different, and it has its characteristics.

What is the architecture and concept behind Apache Kafka?

This section will teach some core concepts of Apache Kafka to understand more in-depth how Kafka works.

Topics

A topic refers to a category in Kafka where producers publish a stream of data from a particular category, and consumers read those data by subscribing to a specific topic. Once data is published within a topic, it’s immutable, and the user can create n number of topics within a Kafka cluster. These topics are quite similar to tables in a database but with no constraints and must be unique so their name can identify them within a Kafka cluster.

Youtube application can be an example of a Kafka Topic, imagine there are tons of creators who create videos from different areas and publish the videos on youtube with a unique channel name. The user first needs to subscribe to these channels to watch the videos and get a notification when a new video is uploaded. So the channel name is nothing but a Kafka topic; each creator pushes content to the specific channels, and the videos get organized in the youtube system.

Partitions

In Kafka, partitions are the smallest storage units, and the messages are stored in the partitions within a particular topic. It’s essential to note that while creating a topic, it’s required to specify the number of partitions. Each message is stored in a partition with an incremental id called offset. This offset value provides guarantees that each message is stored in a partition in a sequenced fashion. There is no limitation to partitions; there can be n number of partitions within a topic.

In the above diagram, the topic contains three partitions. Each partition has different offset values that holds unique individual messages, and the relevant partition gets selected when we write a message to a topic. In this example diagram, Partition 0 starts with offset 0, increments the next offset by +1, and at the 10th offset, the next message should be written and stores the messages in each offset sequentially. Partition 1 has 0 to 5 offsets, and the next message that should be written is the 6th. Similarly, Partition 2 has 0 to 9 offsets; the next message that should be written is the 10th offset. So, all three partition stores the messages in each position independently with their offsets.

Brokers

A Kafka broker is a container that holds different topics and their partitions. Each broker within a cluster also knows as a Bootstrap broker because a broker contains information on all other brokers, partitions, and topics within a cluster. Kafka Brokers store all the data in a server directory, and each topic partition gets its directory with a topic name associated with it. The main architecture behind Kafka Broker is to achieve higher throughput and scalability on topics, and partitions are distributed among brokers evenly within a cluster.

In the above diagram, each broker has two topics (A & B) and each partition is distributed among each broker. It’s essential to understand a single broker does not hold all the partitions of a topic. Similarly, topic B has three partitions, but it is distributed among each broker within a cluster and has no relationship with the topic A partition.

Kafka Broker is highly efficient in distributing partitions among brokers. In high traffic, the Kafka Administrator can move the partition to a different broker and load balance the cluster.

Producers

Kafka Producers is the client that publishes data to topics within different partitions. The main architecture behind producers is to identify automatically which type of data to store on which partition and broker. It’s not required by the user to set any configuration to specify the broker and partition. But in some cases, the user needs to set the preference to specify the partition with a message key to store the message in a specific order.

The message key allows producers to send data to a specific partition, and if the producer doesn’t apply the key, the data will be written to the default round-robin in each partition. This technique is called load balancing, and this process is quite helpful when the traffic is high and allows a producer to write a little bit of data to distributed partition.

In the above diagram, the producer writes data to a Kafka cluster without specifying the key. The data gets distributed among each partition over Topic-A under each broker — (Broker — 01, Broker — 02, and Broker — 03).

In the above diagram, the producer writes data with specifying the key as msg_id, so in partition 0 under Broker 1, the data will be sent as msg_id_1, and in partition 1 under Broker 2, the data will be sent as msg_id_2. The message key concept helps store the data in a specified partition uniquely and retrieve the data by the consumer with the key name.

Consumer and Consumer Groups

To read data from Kafka, it’s quite important to understand consumers and consumer groups, as reading data from Kafka is a bit different than other messaging systems. Kafka uses a KafkaConsumer, which creates a consumer object, subscribes to appropriate Kafka topics, and starts receiving messages from these topics.

The application will create one consumer object within a consumer group and subscribe to the appropriate topic and start receiving messages, this methodology will work when traffic is less. Still, in case of higher traffic, the producers start writing more and more messages on the topic. With a single consumer, the application fails to balance the load with the incoming rate and is unable to read the messages from the topic. To resolve this issue, we definitely need to scale and allow multiple consumers to read data from the same topic. When multiple consumers subscribe to the same topic within the same consumer group, each consumer will receive messages from different partitions of the topic.

In the above diagram, there are 3 consumers within a single consumer group, and it’s the main way to scale the data consumption from a Kafka topic by allowing multiple consumers to a consumer group. So, when there is high traffic, Kafka consumers can balance the load and provide high latency in the application. It’s also essential to understand that there is no point in adding multiple consumers when there is less traffic to the application and fewer partitions; otherwise, some consumers will be just idle.

I’ll publish more in-depth about Kafka Consumers architecture in my future articles.

What is Zookeeper?

Zookeeper is a free and open-source distributed software developed by Apache Software Foundation. Zookeeper act as a centralized service to coordinate and manage Kafka cluster nodes and keeps track of Kafka producers, consumers, topics and partitions.

Zookeeper distributes data over multiple collections of nodes and provides high availability and consistency within a cluster. If a node fails then instantly Zookeeper can performs failover migration and starts a new node in real-time.

The services provided by Zookeeper:

1. Naming Service — In a cluster there are multiple nodes and to identify a node required naming service similar to DNS.
2. Configuration Management — To manage the configuration of the system throughout the life cycle it’s important to have a configuration management system.
3. Cluster Management — To monitor when the node joining / leaving and node status at real time in a cluster, it’s requied to have cluster management.
4. Leader Election — The server that has been selected by ensemble server is called a Leader. A node is elected as leader for coordination purpose.
5. Locking and Synchromization service — The mechanism of locking helps to lock the data while modifying it and helps automatic fail recovery while connecting to other distributed applications.
6. Highly reliable data registry — In case of one or few nodes are down the data always be available.

Zookeeper framework is a highly efficient to manage distributed application, and handled data inconsistency with atomicity and provides various mechanism to overcome with many challenges such as Race condition and deadlock with fail-safe synchronization approach.

I hope you enjoyed reading this article, which gave you an insight into Kafka architecture and how it works. If you think this article helped you in anyways then feel free to share it with your friends.

ACID is a set of properties in database transactions that guarantees data integrity with fault tolerance and ensures it keeps the database in a proper state in the event of unexpected errors. Each database operation that satisfies ACID properties is called a transaction. For example — a high-level function transfers funds from one bank account to another, deducts money from one account, and credits it to another is called a single transaction, and ACID properties guarantee that both accounts should have the same initial amount in case of failures.

In this article, we will explore what a database transaction is, the architecture of a database transaction, and how ACID properties resolve database transaction issues.

What is a database transaction?

Databases are responsible for processing millions of concurrent requests per second and allowing multiple clients to access the same system simultaneously. In other words, a sequence of multiple database transactions is executed on a database as a single logical unit that serves all the operations as a whole. Once the transaction is committed, the changes are applied to the database, and the results are saved.

Let’s look at a typical money transfer example of a database transaction.

There are two accounts, Accounts (A & B), and we need to transfer $100 from Account A to Account B. Let’s assume account A and B has $50 each.

Database Transaction Operations:

1. Check account A’s balance to see whether it has a minimum balance to transfer money.
2. If it has the balance, then subtract $100 from account A.
3. Check account B’s balance before it receives a $100 amount from account A.
4. Add a $100 credit to account B if it still needs to receive the amount.

In the above example, if there is a system failure during the transaction, then the database operation will be rollback to its original state, and both accounts will have the initial amount. Because when the database runs this transaction, it performs as a single logical unit and commits only one transaction.

The architecture of database transactions

The database transaction has several states to complete an operation and typically one of the following:

1. Active State: In every execution of a transaction, it is the first state, and it remains active until the operation fails or is terminated.
2. Partially committed State: Transaction is initiated, and a change has been executed, but the database still needs to commit the whole change on disk instead, it stores the data in the memory buffer.
3. Committed State: In this state, the database executes the final transaction and saves the results in the database. So, we cannot rollback the transaction at this state.
4. Failed State: When a particular transaction fails or is aborted from an active state, it enters a failed state.
5. Terminated State: The final transaction state, either committed or aborted. It is the end of the database transaction.

What are ACID properties?

To maintain the consistency of a database transaction, ACID properties are followed before the execution of a transaction. Let’s learn about all these properties and their advantages.

Atomicity

Atomicity guarantees that all the operations performed to complete a transaction should be treated as a single logical unit, either committed or failed. In that way, we can identify the database state in case of failure and rollback to the original state.

Consistency

Consistency guarantees that all transactions should comply with database constraints. The entire transaction should fail if the data falls into any illegal state.

For example, In a money transfer operation, there are many constraints: the amount should be a positive integer or the overdraw of the amount, the transaction should fail, etc. Because ACID transaction violates consistency properties and transaction fails.

Isolation

To avoid interference between transactions, Isolation guarantees that all transaction operations should perform in an isolated environment so that when multiple transactions run concurrently, they won’t interrupt each other.

For example, there are only two tickets on a booking website. If two people buy the tickets simultaneously, the transaction should run in Isolation so that when both transactions are complete, each person should have one ticket instead of two.

Durability

Durability guarantees that once the transaction operations are completed, and results are stored in the database, they should be persisted. In case of failures or system crashes, data within the system will remain permanent on the disk. However, If the database is lost in case of a crash, the recovery manager guarantees the database's long-term possibilities.

Conclusion

Databases are the key elements to many services and significantly impact our ecosystem. To maintain the database state consistency, it's essential to ensure the integrity and accuracy of the data that ACID transactions provide with different sets of properties. And it’s hard to imagine, without ACID properties, how we can manage or use services and platforms daily.

I hope you enjoyed reading this article, which gave you an insight into ACID properties. If you think this article helped you in anyways then feel free to share it with your friends. If you find any difficulties while following this tutorial, please let me know in the comment section.

Today’s enterprises are increasingly migrating technology platforms and services into the cloud environment of three primary areas — Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). These services help reduce operating costs and improve efficiency within the infrastructure and the ability to scale the platform and deliver the business objective to end-user customers. However, enterprises find difficulties enforcing security compliance to these services because of infrastructure security challenges commonly found in a cloud environment, such as Insufficient Identity Access Management, Vulnerabilities in the platform, Data breaches and many more. The enterprise must address these security risks and enforce countermeasure policies and procedures to mitigate the threat, which can effectively manage and reduce the security risks in the cloud. Every enterprise’s primary challenge is the need for effective cloud security governance that can help optimize the infrastructure security challenges and cloud security problems.

What is Cloud Security Governance?

Cloud security governance is a model of regulations and procedures that enables adequate and efficient security management procedures in the cloud environment so that enterprises can optimize business computing in the cloud by securing the platform, operations and infrastructure. Cloud security governance protocol is specially designed to improve the efficiency and consistency of the cloud infrastructure. This model contains an order of organizational mandates such as operational practices, systems, performance expectations and metrics that will be effective when implemented and create value for the business of an enterprise.

The enterprise can customize cloud governance models for a specific customer. Still, it’s essential to understand the customer’s operational processes and business requirements to implement an effective security governance model within an enterprise. And also, Cloud security governance provides various frameworks based on the organization’s standards because every infrastructure has different operational structures and procedures. As a result, the cloud security governance architecture is customizable to achieve business requirements and targets.

What are Cloud Security Governance Challenges?

The Cloud security governance model is an efficient and effective solution for an enterprise, but the significant challenges the cloud users experience are needing help maintaining these cloud security protocols throughout their business or organizations. The organization’s executive members must understand this security model’s importance and be responsible enough to maintain these models and reach the cloud governance security standards. If the organization’s executive members fail to maintain these standards, the governance model will fail to support business risks, and cloud infrastructure will be vulnerable to cyber-attacks.

Another primary challenge in cloud security governance is assessing a governance model’s effectiveness. It requires estimating the system to measure the security risks that help the governance model prevent security threats and minimize the attack surface.

Cloud Security Governance Framework

In building an efficient cloud security governance model, many customers use a standardized framework appropriate to their infrastructure and follow proper security standards. Many commonly available frameworks are used to develop a security governance model, such as (NIST, IRAP, PCI DSS, ISO, etc.). Utilizing these enterprise standard frameworks allows us to enforce minimum security management and provides guidance and best practices for establishing the governance model for security in the cloud infrastructure. Choosing the appropriate governance framework is necessary to accomplish the security standard, reach the enterprise’s business targets, and protect the data of customers and other assets in the cloud environment.

Once the appropriate framework you’ve chosen then, it’s essential to implement the control mechanism to your cloud infrastructure, including firewalls, logging mechanisms, access management tools and many more. To build a robust security governance model, one must establish the necessary control management.

Disciplines of Cloud Governance

Many common governance disciplines are a good starting point and guide the appropriate level of automation and enforcement of organization policy across cloud platforms.

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/govern/governance-disciplines#disciplines-of-cloud-governance

Cost Management: Cost is a primary concern for cloud users. Develop policies for cost control for all cloud platforms.

Security Baseline: Security is a complex subject, unique to each company. Once security requirements are established, cloud governance policies and enforcement apply those requirements across network, data, and asset configurations.

Identity Baseline: Inconsistencies in the application of identity requirements can increase the risk of breach. The Identity Baseline discipline focuses on ensuring that identity is consistently applied across cloud adoption efforts.

Resource Consistency: Cloud operations depend on consistent resource configuration. Through governance tooling, resources can be configured consistently to manage risks related to onboarding, drift, discoverability, and recovery.

Deployment Acceleration: Centralization, standardization, and consistency in approaches to deployment and configuration improve governance practices. When provided through cloud-based governance tooling, they create a cloud factor that can accelerate deployment activities.

Conclusions

Gaining professional experience in Cloud computing services requires skills and knowledge to mitigate the security risks to the cloud infrastructure and understand the enterprise requirements in depth to reach business goals. Many Cloud Security and Governance certifications enable one to gain critical knowledge, become a professional in this field, solve real-world security governance challenges, and strengthen your network’s proficiency to safeguard against cyber threats.

I hope you enjoyed reading this article, which gave you an insight into Cloud Security Governance. If you think this article helped you in anyways then feel free to share it with your friends. If I still need to include something, let me know with a comment below.

Problem Statement

Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target.

You may assume that each input would have exactly one solution, and you may not use the same element twice.

You can return the answer in any order.

Example 1:

Input: nums = [2,7,11,15], target = 9
Output: [0,1]
Explanation: Because nums[0] + nums[1] == 9, we return [0, 1].

Example 2:

Input: nums = [3,2,4], target = 6
Output: [1,2]

Example 3:

Input: nums = [3,3], target = 6
Output: [0,1]

Constraints:

• 2 <= nums.length <= 104
• -109 <= nums[i] <= 109
• -109 <= target <= 109
• Only one valid answer exists.

Solution

Let’s understand the problem statement. Given an array of integers and a target sum, we need to write an algorithm which returns indices of two elements in an array, so when we add these two elements, it should be equal to the target sum.

In Example — 1: [2, 7, 11, 15] is the given array and the given target sum = 9. If we look at the given array, the sum of pair (2, 7) is 9, i.e. 2 + 7 = 9. The algorithm should return the indices as (0, 1) because the elements 2 and 7 index positions in the given array. And also, we can return the indices in any order, which means either [0, 1] or [1, 0] as output, and both will be correct.

Solution 1 — Brute Force

The first approach to this problem is checking every possible pair in the given array.

Algorithm Steps:

1. Run two nested loops and check for every combination in the given array.
2. Set the outer loop to a specific index and iterate over the inner loop to get all the possible pairs.
3. In each iteration of the inner loop, check if the numbers defined by the outer loop index add up to the target sum.
4. If the array nums[outerIndex] + nums[innerIndex] = target then return [outerIndex, innerIndex] as a result. Or else check the next iteration for the next pair.
5. Repeat the above steps until you find a possible pair that adds up to the given target.

Note: The size of the array element is n.

In the above problem statement, the nums array contains [2, 7, 11, 15] and the target sum=9. By following the brute force approach to solving this problem statement, first, we need to set the outer loop at the index to 0, i.e. i=0 (element 7), and then iterate the inner loop from (j=i+1 to j=n-1) from the index 1 to 3 to find out a possible pair. In the current index, the following pair of elements in the first iteration of the outer loop — (2, 7) (2, 11) and (2, 15). Now we find a combination of (2, 7) in the current index as nums[0] + nums[1] = 9. So the algorithm returns [0, 1] as the possible pair. If we don’t find a pair in the current index then we need to repeat the steps until we find a possible pair.

Program:

Language: Python

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        for i in range(len(nums)):
            for j in range(i + 1, len(nums)):
                if nums[j] == target — nums[i]:
                    return [i, j]

Result:

Runtime: 60ms

Your input: [2, 7, 11, 15]

Output: [0, 1]

Expected: [0, 1]

Complexity Analysis

1. We traverse the array through each element to find the compliment, which takes O(n) time. Therefore the time complexity is O(n2).
2. The size of the input array does not depend on the space, and only constant space is used. Therefore the space complexity is O(1).

Solution 2 — Hashmap

The second approach to solve this problem is Hashmap. We can store the indices of the elements per iteration.

1. Key: The number in the given input array
2. Value: The index value in the given input array

Algorithm Steps

1. Initialize a Hashmap that accepts integer datatype as key and value.
2. Iterate the array through each element starting from index 0.
3. In each iteration, check if the (complementNumber = targetSum — currentArrayValue) is present in the Hashmap.
4. If the complement number is present in the Hashmap, return [requiredArrayIndex, currentArrayIndex] as a result.
5. Else insert the current array value as a key and index as a value to the Hashmap.
6. Repeat the above steps until you find the complement.

Program:

Language: Python

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        nums_dict = {}
        for i in range(len(nums)):
            complement = target - nums[i]
            if complement in nums_dict:
                return [i, nums_dict[complement]]
            nums_dict[nums[i]] = i

Result:

Runtime: 43ms

Your input: [2, 7, 11, 15]

Output: [1, 0]

Expected: [1, 0]

Complexity Analysis

1. We traverse the array through each element only once, and each element iteration costs only O(1).
2. In the Hash table, the number of items stored at most n elements, so extra space required depends on the items. Therefore the space complexity O(n).

I hope you find the article useful. If you think this article helped you in anyways then feel free to share it with your friends. If you think of anything I’ve missed, let me know with a comment below.

Introduction

Load balancing is a technique to distribute tasks and resources across multiple servers and is generally used to improve the performance of the web application, databases and other services. The load balancer keeps track of the health status of each resource while broadcasting requests to each server. If a server cannot respond or raises an error rate, then Load Balancer stops sending traffic to that server.

A load balancer acts as a reverse proxy and sits between client and server, receives incoming traffic and distributes the traffic across clusters of servers using various industry standard load balancing algorithms. Load balancing is an efficient technique to reduce the load of an individual server, improve the application availability, and mitigate the application server from becoming a single point of failure.

Load balancers are typically grouped into two types: Layer 4 and 7. Layer 4 load balancer uses only a TCP connection from a client to the server, while Layer 7 load balancer uses two TCP connections from the client to the server. Layer 7 load balances are based on the data’s content, and Layer 4 load balances are based on its inbuilt software algorithm. Layer 7 is an excellent choice for microservices. However, Layer 4 does not apply to microservices.

Load balancers traffic

There are four main types of traffic the administrators create as forwarding rules.

1. HTTP
2. HTTPS
3. TCP
4. UDP

1. HTTP

The Load Balancer sets the X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port headers to provide the backends information regarding the initial request.

2. HTTPS

Standard HTTPS balances load using encryption, and it is handled in two techniques with SSL passthrough or an SSL termination.

2.1 SSL passthrough

SSL passthrough is the act of handing data via a load balancer to a server without decrypting. The data is passed along to a web server as a simple HTTP, and the decryption or SSL termination occurs at the load balancer.

2.2 SSL termination

SSL termination happens at the load balancer because the decryption process is a very CPU-intensive task. If the load balancer takes the load for decryption, the server spends time processing power on application tasks that helps improve the application performance.

3. TCP

A TCP load balancer uses a transmission control protocol which operates at layer 4, and it’s used to route the traffic to a database cluster distributed across all of the servers.

4. UDP

A UDP load balancer operates at layer 4 in the OSI model and recently added support to core internet protocols such as DNS and syslogd.

Backend Server Health Checks

Healthy backend servers consistently receive incoming traffic from the load balancers. The Load balancer regularly connects with the backend server and checks the health status. If a server fails on a health check and cannot respond to the load balancer, it automatically stops forwarding the traffic to the corresponding server.

Load Balancing Algorithms

A Load balancer uses load balancing algorithms to distribute network traffic between servers. There are two types of load balancing algorithms:

1. Dynamic load balancing algorithms
2. Static load balancing algorithms

Dynamic load balancing algorithms

Dynamic load balancing algorithms use each server’s current state and distribute the traffic accordingly. It is divided into four different types.

1. Least connection
2. Weighted least connection
3. Weighted response time
4. Resource-based

1. Least connection

Load balancers check which server has the fewest connections open and send traffic to those servers, which means all the connections require equal processing power.

2. Weighted least connection

It gives the privilege to the administrator to assign different weights to each server by the assumption that some servers can handle more connections.

3. Weighted response time

The average response time of each server and the number of open connections specify where to send traffic. The algorithm sends traffic to the server with the fastest response time, ensuring quicker service to the end users.

4. Resource-based

Specialized software called agent runs on each server that measures the server’s available CPU and memory. The load balancers query the agent to check what resources are available on each server while distributing the traffic to that server.

Static load balancing algorithms

Static load balancing algorithms send an equal amount of traffic to each server; either it can be random or in a specified order. It is divided into three different types.

1. Round robin
2. Weighted round-robin
3. IP hash

1. Round robin

Round robin load balancing algorithm distributes traffic to clusters of servers in a cycle using DNS. The load balancer selects the first server from the list and then moves down to the second until it reaches the end.

2. Weighted round-robin

It gives the privilege to the administrators to assign different weights to each server so that the servers can handle more traffic. Using DNS records can configure the weighting.

3. IP hash

The combination of incoming traffic’s source and destination IP addresses generates a hash using a mathematical function. The connection is assigned to a specific server by using the generated hash.

How to handle Load Balancers failure?

There are many ways a load balancer can fail within a system. If one load balancer fails, the second load balancer should connect immediately and can become active. The two load balancers can be connected to form a cluster, where each can monitor the status of the other’s heartbeat; each load balancer has equal capability to detect failure and recovery.

When the primary load balancer fails, the DNS should be able to route the application to the second load balancer. But to make changes to the DNS, It will take a minimum of 24 hours to reflect on the internet. To make this process automatic, system administrators use systems like Reserved IPs that allow for elastic IP address mapping. The IP address with the domain name remains the same but is moved between servers.

Conclusion

I hope you enjoyed reading this article, which gave you an insight into Load Balancers. If you think this article helped you in anyways then feel free to share it with your friends. If you think of anything I’ve missed, let me know with a comment below.

Introduction

HTTP headers are the list of strings used to pass information between client and server through request and response headers. These headers are hidden from the end user and only processed or logged by the server and client applications. HTTP headers consist of their case-insensitive name and colon-separated by key-value pair in clear text string format with a Whitespace before the value, terminated by a carriage return (CR) and line feed (LF) character sequence. At the end of the header section, two consecutive CR-LF pairs are marked by the empty field line. HTTP method names (GET, POST, etc.) are case-sensitive, and the header field names are case-insensitive.

HTTP headers are the essential components of the request and response, containing information about the client browser, the target server host, cookie and more. The Internet Engineering Task Force (IETF) standardized the HTTP headers field names in RFC7230, RFC7231, RFC7233, RFC7234 and RFC7235. The IANA maintains the Field Names, Header Fields and Repository of Provisional Registrations.

As per the standard, there is no size limit for HTTP headers. In an HTTP message, there can be as many Headers as possible, but because of security reasons and page loading performance issues, the web servers limit the size of the HTTP headers. For example — the Apache server limits the size of the HTTP headers to 8,190 bytes and 100 HTTP Headers.

HTTP Headers types

1. Request HTTP Headers
2. Response HTTP Headers
3. Representation HTTP Headers
4. Payload HTTP Headers
5. End-to-end HTTP Headers
6. Hop-by-hop HTTP Headers

1. HTTP Request Headers

Standard request fields

Non-standard request fields

2. HTTP Response Headers

Standard response fields

Non-standard response fields

3. Representation Headers

A representation header is an HTTP header representing the individual model of the resource sent in an HTTP message body. A particular resource is always a different representation, meaning the same data is formatted in a specific media type, such as JSON or XML. In each case, the underlying structure of the resource is the same, but the data representation is different.

1. Content-type
2. Content-Encoding
3. Content-Language
4. Content-Location

4. Payload Header

A payload header is an HTTP header representing the message body described to secure transmission and construct the resource representation. The information includes the message payload length, encoding, integrity checks, etc. The payload header presents in both HTTP request and response messages.

1. Content-Length
2. Content-Range
3. Trailer
4. Transfer-Encoding

Lists of HTTP Headers

• HTTP access control (CORS)
• HTTP Authentication
• HTTP Caching
• HTTP Compression
• HTTP Conditional Requests
• HTTP Content Negotiation
• HTTP Cookies
• HTTP Range Requests
• HTTP Redirects
• HTTP Proxies
• HTTP Controls
• HTTP WebSockets
• HTTP Downloads
• HTTP Connection Management

HTTP access control (CORS)

CORS HTTP Headers are related to security HTTP headers that provide a mechanism to indicate the origins of the request. The request and response get processed based on the policy between different origins.

HTTP Authentication

The client and server use the HTTP authentication framework to share authentication information and inspect a client’s request. These headers are used mainly for proxy and webserver authentication. The Web servers can communicate with the user-agent and requestor based on the proxy-server authentication information.

HTTP Caching

HTTP caching headers are used to cache the web page resources such as Images, Javascript, CSS files and other related resources. Caching mechanism is always required to improve the loading performance of the webpage.

HTTP Compression

HTTP compression header is used to compress the web page resources, increasing page loading performance. These compression headers the web developers don’t need to implement by themselves as both browsers and servers implement these compression headers mechanisms by default. But as a practice still, it’s required to check the server configurations.

HTTP Conditional Requests

HTTP conditional header is used for conditional requests where the value of a validator can change the results by comparing the affected resources. The conditional requests are always helpful in validating the content of the cache and performing other useful operations to verify the integrity of a document.

HTTP Content Negotiation

Content negotiation is a mechanism that serves different representations of resources to the same URI, such as which document language, which image format or which content encoding.

HTTP Cookies

Cookie HTTP headers are used to retrieve stored HTTP Cookies from the server. It can also send or receive cookies from web servers.

HTTP Range Requests

HTTP range requests header is used to request the server to send only part of the HTTP message back to the client, and these headers are useful while retrieving large files from the target web server.

HTTP Redirects

HTTP redirects header is used to redirect a web page URL to a particular location using the Location header.

HTTP Proxies

HTTP proxy header provides information for the proxy servers, such as originating IP address, origin host, etc.

HTTP Controls

HTTP Controls header is used to specify how the server handles the request during the transmission of the message.

HTTP WebSockets

HTTP WebSockets headers are used for WebSockets to send and receive data between a web browser and a web server. WebSockets HTTP headers enhance client and web server transmission for two-way interactive sessions.

HTTP Downloads

HTTP Downloads header contains only “Content-Disposition”, which provides a “Save As” dialog option within the browser to display the content inline or usually handled, such as download action.

HTTP Connection Management

HTTP Connection Management header controls the connection request and determines the connection life for how long to keep the connection alive. These headers are essential to maintain the server overload and response time quality.

What is the need for HTTP Headers on a Website?

HTTP Headers are the key to the website, which determine how the web browser will pass messages to the web server and performs different actions based on the HTTP Status Codes, such as redirecting the website to a particular location, etc. HTTP Headers help improve the web page loading performance and security to protect the user’s privacy from cybersecurity issues and vulnerabilities, which are critical for search engine optimization, web server security, etc. HTTP Headers are very useful in enhancing the SEO of the website, which instructs the search engine to index a page using robot directives and improves the ranking of the website. HTTP headers can change the behaviour and functionality of the website by its configurations; they can serve different web pages of a website.

I hope you enjoyed reading this article, which gave you an insight into HTTP Headers. If you think this article helped you in anyways then feel free to share it with your friends. If you think of anything I’ve missed, let me know with a comment below.

Introduction

The HTTP or Hypertext Transfer Protocol is an application layer control protocol for transmitting hypermedia documents such as graphics, audio, video, plain text and hyperlinks on the World Wide Web. To obtain information from the target web server, the client makes a request and keeps the Connection open until it receives a response. HTTP is a stateless protocol that means the target server does not support information between two requests.

Since the evolvement of HTTP/1.1 in 1997, this version was the standardized communication protocol in RFC 2068 until the HTTP/2 protocol was introduced in 2015 by IETF (Internet Engineering Task Force). HTTP/2 protocol version was introduced to decrease latency, increase speed and enable complete request and response multiplexing, which means when the client opens a connection to the target web server, it can send multiple requests and receive multiple responses with a single line of communication.

Now, let’s dive deep into these two protocols and understand the main difference between HTTP/1.1 and HTTP/2 and the technical changes HTTP/2 has adopted in the modern World Wide Web.

What is HTTP/1.1?

In 1989 Timothy Berners Lee developed a communication protocol for the World Wide Web called Hypertext Transfer Protocol that exchanges data between a client and a remote web server. When a client visits a website on his browser, for example — www.google.com, it sends a request to the remote web server and waits until the server sends a response; in this communication, the server acknowledges it with an HTML page.

To send a particular request client calls methods like GET or POST, which later be interpreted by HTTP and processed to the remote web server.

GET /index.html HTTP/1.1
Host: www.google.com

The above HTTP request is an example of a GET method, and it requests the remote Host: to get the resources of www.google.com and the web server returns an HTML with all the necessary resources like CSS, js, images, etc. But all these contents are not returned to the client at once in a single request. To render the complete HTML page on the web browser, the client sends multiple requests to receive all the resources from the target web server; once the web browser receives all the resources, it displays the complete HTML web page on the screen.

What is HTTP/2?

HTTP/2 is a primary revision of HTTP/1.1 and derived from the SPDY protocol, which Google originally developed as a way to improve the web page loading performance by reducing the latency using the technique such as complete request and response multiplexing, efficient Compression of HTTP header fields, enabling request prioritization and server push.

The HTTP Working Group developed HTTP/2, also called as httpbis, of the Internet Engineering Task Force (IETF). The Working Group first presented the HTTP/2 protocol research to the Internet Engineering Steering Group (IESG) on December 2014, and later IESG approved it on February 17, 2015. The specification for HTTP/2 was published as RFC-7540 on May 14, 2015. The protocol is supported by many standardized browsers Chrome, Firefox, Safari, Opera and many more.

The architecture behind HTTP/2 is the binary framing layer which sends all the requests and responses in binary format and maintains HTTP semantics such as methods and headers. When the client makes a request using a high-level API, it still constructs the messages in traditional HTTP formats. Still, it’s essential to understand that all these messages are converted into binary at a low level. HTTP/2 version has many features and evolved significantly by transforming messages from plain text to binary, allowing this protocol to deliver the message faster and more efficiently.

As of now, we understand the typical difference between these two protocols and ensure that both protocols use the same HTTP semantics such as headers, methods and verbs. To send messages, HTTP/1.1 uses the plain text technique, and HTTP/2 transform the messages into binary. In the next section, we will briefly discuss how HTTP/1.1 uses different methods to send messages and what challenges occurred and were resolved by the HTTP/2 using the binary framing layer technique.

Head Of Line blocking in HTTP/1.1

In computer networking, Head-of-line blocking (HOL blocking) is a performance-limiting phenomenon that occurs when a group of packets are in the queue by the first packet in line. For example — when the client or browsers have restrictions on accessing a server, and a new request waits for the previous request to complete before it can be processed.

In HTTP/1.1 (HOL), blocking occurs because when a client opens a TCP connection, it sends multiple requests with the same Connection without waiting for a response. After all, HTTP/1.1 protocol creates persistent connections by default without specifying the Connection: keep-alive header that allows multiple requests to be sent over the same TCP connection using the pipeline technique. However, the pipeline improves the loading time performance of the webpage but also creates a HOL blocking issue because processing one request or response takes a longer time, which causes a delay in retransmitting other requests and responses.

HTTP/2 fixes HOL blocking issues using the binary framing layer technique that improves the connection efficiency and allows multiple connections to increase the flexibility of transmitting information to the desired destination. In the next section, we will learn more about the binary framing layer technique and its advantages.

HTTP/2 — Binary Framing Layer

The binary framing layer converts requests/responses into binary and breaks them into smaller chunks to form a bidirectional communication stream. HTTP/2 establishes a single TCP connection between the client and the server, and during the Connection, there are multiple streams of data transfers between two machines.

Each stream contains multiple messages in request/response form, which are divided into smaller units called Frames. HTTP/2 concurrently can open various streams within a single connection and can assign frames from other streams on the Connection. A Stream is a bidirectional flow of frames between two machines, and What can also share Streams between the client and the server.

The architecture behind HTTP/2 consists of a group of binary-encoded frames within a single communication channel that is tagged to a particular stream. Each frame is the smallest unit of communication that contains a specific type of data — For example, HTTP Headers, messages, etc. Those frames are from different streams interleaved and reassembled via an embedded stream identifier in each frame’s header. The interleaved requests and responses run in parallel without blocking the messages behind them and confirm no messages have to wait for another to finish, and this methodology is called multiplexing.

The multiplexing technique allows servers and clients to send concurrent requests and responses for more efficient connection management within a single TCP connection and also reduces the latency, improves the network and bandwidth utilization and lowers the operational cost throughout the network. To secure the communication throughout the channel, the client and the server can reuse the same secured session for multiple requests and responses because during TLS or SSL handshaking, both the machines agree to use a single key throughout the session; if the session ends a new key will generate for further communication that also improves the performance of HTTPS protocol.

As a final thought, multiplexing with a binary framing layer improves the performance of TCP communication and solves a couple of issues of the HTTP/1.1 protocol. But still, within a channel, awaited streams use the same resources that cause performance issues. In the next section, we will learn how stream prioritization optimizes application performance and manage resources.

HTTP/2 — Stream Prioritization

Stream Prioritization is a technique that allows customization of requests’ relative weight to optimize application performance and solves potential requests competition for the same resource. The prioritization technique is essential to understand better, so you can take benefit of this feature of HTTP/2.

The binary framing layer manages requests/responses into a parallel data stream. When a server receives concurrent client requests, it prioritizes the responses by setting a weight between 1 and 256 per stream. If the number is higher, then that is the higher priority. An Identifier specifies each stream’s dependency on another stream by the client, so it’s easier to identify the dependant of the stream. When there is no parent stream ID, the root stream is considered as the stream’s dependent.

The client constructs and communicates a prioritization tree by combining stream dependencies and their weight, showing how the client would prefer to receive the responses. The server utilizes this information to prioritize stream processing by controlling resource utilization, such as allocating CPU, memory, and other resources. When the response data is ready to send to the client, it ensures bandwidth allocation is better so it can able to deliver high-priority responses to the client. Streams that share the same parent should allocate resources in proportion to their weight.

Let’s see a few examples to get hands-on with stream allocation.

Examples

Author, Ilya Grigorik (Year). Title of the article. High-Performance Browser Networking, Stream Prioritization.

If stream A has a weight of 12 and its one sibling B has a weight of 4, then to determine the proportion of the resources that each of these streams should receive:

Sum all the weights: 4 + 12 = 16

Divide each stream weight by the total weight: A = 12/16, B = 4/16

Thus, stream A should receive three-quarters and stream B should receive one-quarter of available resources; stream B should receive one-third of the resources allocated to stream A. Let’s work through a few more hands-on examples:

Neither stream A nor B specify a parent dependency and are said to be dependent on the implicit “root stream”; A has a weight of 12, and B has a weight of 4. Thus, based on proportional weights: stream B should receive one-third of the resources allocated to stream A.

D depends on the root stream; C depends on D. Thus, D should receive full allocation of resources ahead of C. The weights are inconsequential because C’s dependency communicates a stronger preference.

D should receive full allocation of resources ahead of C; C should receive full allocation of resources ahead of A and B; stream B should receive one-third of the resources allocated to stream A.

D should receive full allocation of resources ahead of E and C; E and C should receive equal allocation ahead of A and B; A and B should receive a proportional allocation based on their weights.

As we saw in the above examples by Ilya Grigorik, resource prioritization is crucial in improving browsing performance in today’s modern web applications with the combination of stream dependencies and weights.

And also, HTTP/2 allows the client to change the preferences at any moment, enabling further enhancement to the browser, which means we can reallocate weights in response, and update the dependencies, to enhance the user browsing experience.

Resource Inlining vs Server Push

In every web application, when a client sends a GET request to the target web server in the first response, it only accepts the website’s index page. But to render the complete web page on the browser still requires fetching additional resources such as CSS, Javascript and other media files. So, the client makes further requests to bring other resources but increases latency and web page load time and consumes more bandwidth.

This section will discuss how HTTP/1.1 and HTTP/2 follow different methodologies to improve the web page loading time and reduces bandwidth consumption.

HTTP/1.1 — Resource Inlining

In HTTP/1.1, resource inlining is a technique to include the required resources with the HTML document so that the server can send all the resources in the response at the initial request. For example — To render the complete web page, the index.html file requires additional resources; inlining these resources with the index file will reduce the total number of network calls. This technique is only feasible for text-based resources. However, inline, a large file with an HTML document can significantly increase the HTML document’s size and reduces the network speed, delaying response to the client.

The major drawback of resource inline is that the client cannot separate the inlined resources from an HTML document or cache the resources in a particular state. And if every web page on the site is inline with the same resource, it will increase the HTML document’s size and reduce the web page loading time.

The resource inlining technique is not optimal for decreasing the web page loading time and increasing the connection speed. In the next section, we will learn how HTTP/2 uses server push methodology to optimize the web page connection.

HTTP/2 — Server Push

In HTTP/2, as we know, it sends multiple concurrent responses to the client’s requests. The target web server can send additional resources along with the HTML document without the client’s request for the resource, and this process is called server push. HTTP/2 even maintains the separation between pushed resources and HTML documents by using this technique, which resolves the issue of resource inlining as the client can either cache the resource or decline the pushed resources from the HTML document.

The technique behind this process is that the server will send a PUSH_PROMISE frame to notify the client that it will send a pushed resource. The frame only includes the header of the message, and the client knows which type of resource the server will push before sending the request. In this technique, if the client already cached the existing resource, it can decline the pushed resource by sending an RST_STREAM frame in the response. As the client knows ahead of time which resources the server will send, it holds the client from sending duplicate requests.

The client has complete control over server push that can adjust the priority or even disable the server push; whenever required, it will only send a SETTINGS frame to change the HTTP/2 component.

The server push has many features but is still not supported by the many web browsers that disable many critical components for the client, such as cancelling a cached resource, allowing duplicate resources, etc. And this technique should be used based on the requirement of the web application.

To read more on web application optimization and server push, you can check out the PRPL pattern developed by Google.

Header Compression

The most common message between the client and server in every HTTP transmission is the HTTP headers. These headers are always sent as plain text of around 500–800 bytes per transfer; if the header contains a cookie, the size can be up to kilobytes. To reduce the size of the HTTP messages, HTTP uses various compression algorithms so that the web application performance can be increased and transferring of messages can be faster.

HTTP/1.1 — gzip compression

In HTTP/1.1, a program like gzip compression software is used to compress the size of CSS and JavaScript files to reduce the data size. But the major problem in HTTP/1.1 is that the headers are always transferred in plain text, which increases the message’s size. When API has many different features and resources, such as Cookies and additional headers, the weight of the messages becomes heavy and increases the latency transfer rate.

To solve the header compression issue, HTTP/2 has a compression feature, HPACK, which we will discuss in the next section.

HTTP/2 — HPACK Compression

In HTTP/2, compressing the header is different; it divides the header from the data and keeps it in a header and data frame. To compress the header frame, HTTP/2 uses the compression software HPACK. The algorithm behind this compression program is Huffman coding which encodes the header metadata and reduces the size of the header.

The HPACK also keeps track of the previous header metadata, which will only compress the altered field in the subsequent request.

Request — 1
— — — — — —
method: GET
scheme: https
host: example.com
path: /blog
accept: /image/png
user-agent: Mozilla/5.0…

Request — 2
— — — — — —
method: GET
scheme: https
host: example.com
path: /blog/17885642
accept: /image/png
user-agent: Mozilla/5.0…

In the above requests, the only path header uses different values that update dynamically in the subsequent request. So, in Request — 2, the HPACK will only compress the path header metadata and restore the most common and newly encoded path fields.

To learn more on HPACK, you can also refer to RFC7541.

Conclusions

There are many significant differences between HTTP/1.1 and HTTP/2 in terms of features and techniques to improve web application performance. As we’ve seen, both the protocols’ implementations to enhance the web are entirely different. HTTP/2 changes the web architecture by implementing various methods such as multiplexing, stream prioritization, flow control, server push and compression that transform the web application to the next level.

I hope you enjoyed reading this article, which gave you an insight into the difference between HTTP/1.1 and HTTP/2. If you think this article helped you in anyways then feel free to share it with your friends. If you think of anything I’ve missed, let me know with a comment below.