DEV Community: JAYA SRI J

consistency

JAYA SRI J — Sun, 29 Mar 2026 17:17:39 +0000

Let us start with the accounts table, which stores user balance information.

CREATE TABLE accounts (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
balance INT NOT NULL CHECK (balance >= 0),
last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Here, the most important rule is the CHECK constraint on balance. It ensures that the balance can never go below zero. This is a database-level safety mechanism that protects against invalid data.

Now, insert some sample data.

INSERT INTO accounts (name, balance) VALUES ('Alice', 1000), ('Bob', 500);

At this stage, both users have valid balances, and the system is consistent.

Now consider a situation where Alice tries to send more money than she has. For example, deducting 1500 from Alice’s account.

UPDATE accounts SET balance = balance - 1500 WHERE name = 'Alice';

PostgreSQL will reject this operation because it violates the CHECK constraint (balance >= 0). The database will throw an error and prevent the update from happening. This shows that the database itself enforces rules to maintain valid data.

Next, consider directly trying to set a negative balance.


UPDATE accounts SET balance = -200 WHERE name = 'Bob';

Again, PostgreSQL will block this operation because it breaks the CHECK constraint. This confirms that constraints act as a safety net at the database level.

However, not all problems can be solved using constraints alone. Consider a money transfer between two users. A transfer involves two steps: deducting money from one account and adding it to another. If one step succeeds and the other fails, the system becomes inconsistent.

To handle this, we use transactions.

BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 300 WHERE name = 'Bob';
COMMIT;

If both operations succeed, the transaction is committed and the system remains consistent. But if any error occurs in between, we can roll back the entire transaction.

ROLLBACK;

This ensures that either both operations happen or none happen, preventing partial updates.

Now consider a failure scenario where the first query runs but the second fails due to some error. Without a transaction, Alice’s balance would be reduced but Bob would not receive the money. This leads to money loss. With transactions, the system automatically rolls back and restores the original state.

From these observations, we can clearly distinguish two types of rules.

Application or transaction-level rules handle complex operations like money transfers. These ensure that multiple related operations are executed safely and completely.

create tabel

JAYA SRI J — Sun, 29 Mar 2026 17:03:21 +0000

Create a table called students where each student has an id, name, and age, and ensure that the id uniquely identifies each student.

CREATE TABLE students (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    age INT
);

Create a table employees where name and email cannot be empty, but phone_number can be optional.

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) NOT NULL,
    phone_number VARCHAR(15)
);

Create a table users where both username and email must be unique across all records.

CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50) UNIQUE,
    email VARCHAR(100) UNIQUE
);

Create a table products where price must always be greater than 0 and stock cannot be negative.

CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10,2) CHECK (price > 0),
    stock INT CHECK (stock >= 0)
);

Create a table orders where status should default to 'pending' if no value is provided, and created_at should store the current timestamp automatically.

CREATE TABLE orders (
    id INT PRIMARY KEY,
    status VARCHAR(20) DEFAULT 'pending',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Create a table accounts where account_number must be unique and not null, and balance must always be greater than or equal to 0.

CREATE TABLE accounts (
    id INT PRIMARY KEY,
    account_number VARCHAR(20) UNIQUE NOT NULL,
    balance DECIMAL(10,2) CHECK (balance >= 0)
);

Create a table enrollments where a student can enroll in multiple courses, but the combination of student_id and course_id must be unique.

CREATE TABLE enrollments (
    student_id INT,
    course_id INT,
    PRIMARY KEY (student_id, course_id)
);

Create two tables: departments with id and name, and employees with id, name, and department_id, ensuring that department_id in employees must exist in departments.

CREATE TABLE departments (
    id INT PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    department_id INT,
    FOREIGN KEY (department_id) REFERENCES departments(id)
);

Modify the previous foreign key example so that when a department is deleted, all related employees are also deleted, and when a department ID is updated, it reflects in the employees table.

CREATE TABLE departments (
    id INT PRIMARY KEY,
    name VARCHAR(100)
);

CREATE TABLE employees (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    department_id INT,
    FOREIGN KEY (department_id)
        REFERENCES departments(id)
        ON DELETE CASCADE
        ON UPDATE CASCADE
);

ALTER

JAYA SRI J — Sun, 29 Mar 2026 15:48:39 +0000

To ensure that every customer must provide an email in the future, we need to prevent NULL values in the email column. This enforces data completeness and avoids issues like missing contact information.

ALTER TABLE customers ALTER COLUMN email SET NOT NULL;

This change guarantees that all future inserts must include an email value.

Usernames are typically used for login or identification, so they must be unique. To enforce this at the database level, we add a unique constraint.

ALTER TABLE users ADD CONSTRAINT unique_username UNIQUE (username);

This prevents duplicate usernames and ensures consistency across the system.

In a products table, price should never be zero or negative. To enforce this rule, we add a check constraint.

ALTER TABLE products ADD CONSTRAINT check_price_positive CHECK (price > 0);

This ensures that only valid product prices are stored.

For an orders table, it is common to assign a default status when none is provided. This avoids NULL values and keeps workflows predictable.


ALTER TABLE orders ALTER COLUMN status SET DEFAULT 'pending';

Now, if no status is specified during insertion, it will automatically be set to 'pending'.

When adding a salary column to the employees table, we must ensure two things: it cannot be NULL and it must be greater than 10,000. This requires both a column addition and constraints.


ALTER TABLE employees ADD COLUMN salary INT NOT NULL CHECK (salary > 10000);

This enforces both presence and validity of salary values.

ALTER TABLE employees DROP CONSTRAINT employees_department_id_fkey;
ALTER TABLE employeesADD CONSTRAINT employees_department_id_fkey FOREIGN KEY (department_id) REFERENCES departments(id) ON DELETE CASCADE;

This ensures referential integrity by automatically cleaning up dependent records.

Sometimes business rules change, and constraints need to be removed. For example, if the accounts table no longer requires balance to be non-negative, we can drop the check constraint.

ALTER TABLE accounts DROP CONSTRAINT accounts_balance_check;

This removes the restriction and allows more flexible balance values.

To ensure that each payment is uniquely identified per user, we enforce a composite unique constraint on user_id and transaction_id.

ALTER TABLE payments ADD CONSTRAINT unique_user_transaction UNIQUE (user_id, transaction_id);

This prevents duplicate transactions for the same user.

Atomicity

JAYA SRI J — Sun, 29 Mar 2026 15:42:50 +0000

** 1: Initial Setup**

We already have the accounts table:

CREATE TABLE accounts (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
balance INT NOT NULL CHECK (balance >= 0),
last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Insert dummy data:

INSERT INTO accounts (name, balance) VALUES ('Alice', 1000),('Bob', 500);

** 2: Check Initial State**

SELECT * FROM accounts;

Output:

Alice is 1000
Bob is 500

This is our starting point.

** 3: Correct Money Transfer**

We transfer 200 from Alice to Bob.

BEGIN;

UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 200 WHERE name = 'Bob';

COMMIT;

Explanation:

BEGIN starts the transaction next update deducts money from Alice.Then update adds money to Bob.COMMIT saves changes permanently

After Transaction

SELECT * FROM accounts;

Alice is 800
Bob is 700

This is correct behavior.

4: Failure Scenario

Now we simulate a failure after deducting money.

BEGIN;

UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice';

Simulated error

UPDATE accounts SET balance = balance + 200 WHERE nam = 'Bob';
COMMIT;

What Happens Here?

First query succeeds belongs Alice becomes 800
Second query fails belongs column error
Transaction stops
Important Point

Since an error occurred, the transaction is not committed.

Check Data

SELECT * FROM accounts;

Result
Alice is 1000
Bob is 500
Explanation

Even though the debit query ran, the database rolled back everything.

This proves Atomicity:
Either both updates happen, or none happen.

5: Failure Scenario

BEGIN;
UPDATE accounts SET balance = balance - 2000 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 2000 WHERE name = 'Bob';
COMMIT;

What Happens?
Alice’s balance would go negative But we have a constraint: CHECK (balance >= 0)
So the query fails
Final State

SELECT * FROM accounts;

Alice is 1000
Bob is 500
Explanation

The database prevents invalid data and rolls back the transaction.

Step 6: Failure Scenario

BEGIN;
UPDATE accounts SET balance = balance - 200 WHERE name = 'Alice';
ROLLBACK;

Result
Transaction is canceled manually,No changes are saved
Final State
Alice is 1000
Bob is 500

Step 8: Real-World Improvement

In real systems, we also add:

BEGIN;
UPDATE accounts SET balance = balance - 200WHERE id = 1 AND balance >=200;
UPDATE accounts SET balance = balance + 200 WHERE id = 2;
COMMIT;

filter assigment

JAYA SRI J — Sun, 29 Mar 2026 15:29:45 +0000

1. Movies where special features are not listed

Sometimes data is missing. In SQL, missing values are stored as NULL.

SELECT * FROM film WHERE special_features IS NULL;

Explanation
We cannot use = with NULL because NULL means "unknown" So we use IS NULL to check if the column has no value.

2. Movies with rental duration more than 7 days

SELECT *  FROM film WHERE rental_duration > 7;

Explanation

We use > to filter movies whose rental period is greater than 7 days.

3. Movies with rental rate 4.99 and replacement cost > 20

SELECT * FROM film WHERE rental_rate = 4.99 AND replacement_cost > 20;

Explanation

AND means both conditions must be true We are filtering premium movies that are costly to replace.

4. Movies with rental rate 0.99 or rating PG-13

SELECT * FROM film WHERE rental_rate = 0.99 OR rating = 'PG-13';

Explanation

OR means either condition can be true This helps find cheap movies or specific rated movies.

5. First 5 movies sorted alphabetically

SELECT * FROM film ORDER BY title ASC LIMIT 5;

Explanation

ORDER BY sorts the titles alphabetically the LIMIT 5 ensures only the first 5 records are shown.

6. Skip first 10 and fetch next 3 highest replacement cost

SELECT * FROM film ORDER BY replacement_cost DESC LIMIT 3 OFFSET 10;

Explanation

We first sort movies by highest replacement cost OFFSET 10 skips the first 10 rows LIMIT 3 gives the next 3 rows.

7. Movies with rating G, PG, or PG-13

SELECT * FROM film WHERE rating IN ('G', 'PG', 'PG-13');

Explanation

IN is used when checking multiple values is cleaner than writing multiple OR conditions.

8. Movies with rental rate between 2 and 4

SELECT * FROM film WHERE rental_rate BETWEEN 2 AND 4;

Explanation

BETWEEN includes both 2 and 4 it simplifies range conditions.

9. Movies with titles starting with "The"

SELECT * FROM film WHERE title LIKE 'The%';

Explanation

LIKE is used for pattern matching % means any characters after "The".

10. First 10 movies with multiple conditions

SELECT * FROM film WHERE (rental_rate = 2.99 OR rental_rate = 4.99)
AND rating = 'R'AND title LIKE '%Love%' LIMIT 10;

Explanation

We combine conditions:

rental rate is either 2.99 or 4.99 ,rating must be R and title must contain "Love"

11. Titles containing % symbol

SELECT * FROM film WHERE title LIKE '%\%%' ESCAPE '\';

Explanation

% is normally a wildcard it search the literally, we escape it using .

12. Titles containing underscore (_)

SELECT * FROM film WHERE title LIKE '%\_%' ESCAPE '\';

Explanation

_ means one character in SQL it escape it to treat it as a normal character.

13. Titles starting with A or B and ending with s

SELECT * FROM film WHERE title LIKE 'A%s' OR title LIKE 'B%s';

Explanation
A%s ---> starts with A, ends with s
B%s ---> starts with B, ends with s

14. Titles containing Man, Men, or Woman

SELECT * FROM film WHERE title LIKE '%Man%' OR title LIKE '%Men%' OR title LIKE '%Woman%';

Explanation
We search for specific words inside the title using %.

15. Titles containing digits

SELECT * FROM film WHERE title REGEXP '[0-9]';

16. Titles containing backslash ()

SELECT * FROM film WHERE title LIKE '%\\\\%';

Explanation

Backslash is a special escape character So we use double escaping (\\) to match a single .

Titles containing "Love" or "Hate"

SELECT * FROM film WHERE title LIKE '%Love%' OR title LIKE '%Hate%';

Explanation
We check if either word exists anywhere in the title.

18. First 5 movies ending with "er", "or", or "ar"

SELECT * FROM film WHERE title LIKE '%er' OR title LIKE '%or' OR title LIKE '%ar'LIMIT 5;

Explanation

%er, %or, %ar means titles ending with those suffixes the LIMIT 5 restricts output.

select queries

JAYA SRI J — Thu, 26 Mar 2026 15:20:27 +0000

let's see about different queries and how it works
1. Retrieve Film Titles and Rental Rates

SELECT title "Movie Title", rental_rate "Rate" FROM film;

Explanation
here I ma doing title is renamed as "Movie Name" and rental_rate is renamed as rate
here why I use string----> when you give space without using string it does not exists.
here without AS or with As no problem both is acceptable

2. Retrieve Customer Names and Email
Query

SELECT first_name "First Name", last_name "Last Name", email FROM customer;

Explanation
first_name is renamed to "First Name". and last_name is renamed to "Last Name".
email is left unchanged because it is already clear.

3.Films sorted by rental rate (descending), then title

SELECT title, rental_rate FROM film ORDER BY rental_rate DESC, title ASC;

Explanation
DESC is for highest first and ASC is for alphabetical.
Used for ranking + tie-breaking.

4. Actor names sorted by last name, then first name

SELECT first_name, last_name FROM actor ORDER BY last_name, first_name;

Explanation:
Standard way to sort names .

5. Unique replacement costs

SELECT DISTINCT replacement_cost FROM film;

Explanation:
Distinct removes duplicates is useful for analysis.

6. Film title and duration

select title, length AS "Duration (min)" FROM film;

Explanation:
Alias makes unit clear.
**

Customer active status** SELECT first_name, last_name, active AS "Is Active" FROM customer;

Explanation:
Boolean values become user-friendly labels.

8. Film categories alphabetically

SELECT name FROM category ORDER BY name;

Explanation:
Sorting improves readability.

9. Films sorted by length (descending)

SELECT title, length FROM film ORDER BY length DESC;

Explanation:
Find longest movies quickly.

10. Actor names sorted by first name (descending)

SELECT first_name, last_name FROM actor ORDER BY first_name DESC;

explanation:
Reverse sorting for different views.
**

Unique ratings**

SELECT DISTINCT rating FROM film;

explanation:
Know all available categories (PG, R, etc.).

12. Unique rental durations

SELECT DISTINCT rental_duration FROM film;

explanation:
Understand available rental plans.

13. First unique customer by active status

SELECT DISTINCT customer_id, active FROM customer ORDER BY customer_id;

explanation:
Combining DISTINCT + ORDER BY helps identify unique records in order.
**

Earliest rental date for each customer**

SELECT customer_id, MIN(rental_date) AS first_rental FROM rental GROUP BY customer_id ORDER BY customer_id;

explanation:
GROUP BY groups data MIN() used to finds earliest value

15. 10 shortest films

SELECT title, length FROM film ORDER BY length ASC LIMIT 10;

explanation:
LIMIT restricts output of useful for top/bottom lists.

16. Top 5 customers

SELECT first_name, last_name FROM customer ORDER BY customer_id DESC LIMIT 5;

explanation:
It is used to find latest or highest records.
**

Unique store ID**s

SELECT DISTINCT store_id FROM inventory;

explanation:
Identify all store locations.
**

Unique replacement cost (sorted)**

SELECT DISTINCT replacement_cost FROM film ORDER BY replacement_cost ASC;

explanation:
Sorting helps in analysis.

19. First rental date for each store

SELECT store_id, MIN(rental_date) AS first_rental FROM rental GROUP BY store_id ORDER BY store_id;

explanation:
Track store activity start.

20. Unique ratings sorted

SELECT DISTINCT rating FROM film ORDER BY rating;

explanation:
Cleaner categorized output.

21. Films by rating and length

SELECT title, rating, length FROM film ORDER BY rating ASC, length DESC;

explanation:
Multi-level sorting.

*22. Actor names sorted *

SELECT first_name, last_name FROM actor ORDER BY last_name ASC, first_name DESC;

explanation:
Advanced sorting combinations.

23. Films by replacement cost and rental rate

SELECT title, replacement_cost, rental_rate FROM film ORDER BY replacement_cost ASC, rental_rate DESC;

explanation:
Useful for pricing analysis.

24. Customers sorted by name

SELECT first_name, last_name FROM customer ORDER BY last_name ASC,first_name DESC;

explanation:
Readable listing format.

25. Rentals sorted by customer and date

SELECT *FROM rental ORDER BY customer_id ASC, rental_date DESC;

explanation:
See latest activity per customer.

26. Films by rental duration and title

SELECT title, rental_duration FROM film ORDER BY rental_duration ASC, title DESC;

explanation:
Helps compare short vs long rental plans.

idempotency situation

JAYA SRI J — Wed, 25 Mar 2026 15:56:34 +0000

Idempotency is executing the same operation multiple times that will result in the same final state

Situation:

Imagine there are 2 accounts A which has a balance of 300 and B which has a balance of 100
If A initiates a transfer of 50 to B,

first transfer:
A sends B 100, A=300-50--> 250, B=100+50--> 200.

second transfer:
A sends B 100 again, A=200-50 --> 150, B=200+50--> 250.

From the situation, we can see that:

The system processes each request independently.
There is no mechanism to detect duplicates.
The same transaction is applied multiple times.

Result:

Incorrect account balances
Loss of data integrity
inconsistency

QUERIES

JAYA SRI J — Wed, 25 Mar 2026 15:52:25 +0000

1. Select All

Problem: Show all columns from the CITY table.

SELECT * FROM CITY;

This query displays all the data in the table.

Select By ID

Problem: Get details of the city with ID = 1661.

SELECT * FROM CITY WHERE ID = 1661;

The WHERE clause is used to filter a specific row.

3. Japanese Cities Name

Problem: Get names of all cities in Japan.

SELECT NAME FROM CITY WHERE COUNTRYCODE = 'JPN

Only the NAME column is selected here.

4. Japanese Cities Attributes

Problem: Get all details of cities in Japan.

SELECT * FROM CITY WHERE COUNTRYCODE = 'JPN';

This query returns all columns for cities in Japan.

5. Revising the Select Query

Problem: Get all American cities with population greater than 100000.

SELECT * FROM CITY WHERE COUNTRYCODE = 'USA' AND POPULATION > 100000;

Multiple conditions are combined using AND.

6. Revising the Select Query 2

Problem: Get names of American cities with population greater than 120000.

SELECT NAME FROM CITY WHERE COUNTRYCODE = 'USA' AND POPULATION > 120000;

Only the NAME column is required in this case.

*7. Weather Observation Station 1
*
Problem: Show CITY and STATE.

SELECT CITY, STATE FROM STATION;

This query selects two specific columns.

8. Weather Observation Station 4

Problem: Find the difference between total CITY entries and unique CITY entries.

SELECT COUNT(CITY) - COUNT(DISTINCT CITY) FROM STATION;

This calculates how many duplicate city names exist.

9. Weather Observation Station 9

Problem: Get city names that do not start with vowels.


SELECT DISTINCT CITY FROM STATION WHERE CITY NOT LIKE 'A%' AND CITY NOT LIKE 'E%' AND CITY NOT LIKE 'I%' AND CITY NOT LIKE 'O%' AND CITY NOT LIKE 'U%';

DISTINCT removes duplicates, and NOT LIKE filters out cities starting with vowels.

how DNS happening

JAYA SRI J — Wed, 25 Mar 2026 15:29:26 +0000

first let see as flow:

      user----> DNS query initialization----> sub resolver [local machine]

example:
www.wikipedia.org.
here last [.] represent root
org represents TLD [Top level domain]
Wikipedia represents SLD [secondary level domain]
www represents Zone file

                root [name server]
                /         |       \
               /          |        \
              /           |         \
           .org           .com     .in
          [Name server]
           /
          /
         /
    Wikipedia [name server]
       /
      /
     /
 www ------> IP

zone file :
A -----> IPV4
AAAA----> IPV6
mx-------> mail

When your browser needs to resolve a domain (like www.wikipedia.org.), it doesn’t directly go to root servers first.

It usually goes to a DNS resolver provided by your ISP (Internet Service Provider).

Here’s the real-world flow:

You Type a Website www.wikipedia.org.
Browser Checks Cache

If not found → continue

Request Goes to ISP DNS Resolver

Your device sends the request to:
Your ISP’s DNS server

Example:

Airtel DNS
Jio DNS

This server is called a recursive resolver

ISP Resolver Checks Cache If it already knows → returns IP immediately If not → it starts querying:
ISP Contacts Root Server org[.]

“Where is www.wikipedia.org.?”

ISP Contacts TLD Server org.

“Where is www.wikipedia.org.?”
7.next it goes to SLD here it has the Ip address
where is www.wikipedia.org.

zone file is www it has IPV4 :A IPV6:AAAA MX: MAIL

how a request originates from client and reaches server

JAYA SRI J — Wed, 25 Mar 2026 15:19:10 +0000

How a Request Travels from Client to Server

Every time you open a website, send a message, or watch a video online, something fascinating happens behind the scenes. A simple action—like typing a URL—sets off a chain reaction across the internet.

But how exactly does your request travel from your device (the client) to a server somewhere in the world?

Step 1: You Make a Request

It all starts with you.

You open your browser and type something like:

www.wikipedia.org.

At this moment, your device (phone, laptop, etc.) becomes the client, and it’s asking:

“Hey, can I see this website?”

Step 2: The Browser Checks Cache

Before going out to the internet, your browser does a quick check:

“Do I already have this data saved?”

If yes, it loads instantly.
If not, it proceeds to the next step.

This saves time and reduces unnecessary network traffic.

Step 3: DNS — Finding the Server’s Address

Humans use names like wikipedia.org, but computers need numbers.

So your system contacts a DNS (Domain Name System) server to translate the domain into an IP address.

Think of DNS as the internet’s phonebook.

Example:

www.wikipedoa.org → 10.1.34.81

Now your device knows where to send the request.

Step 4: Building the Request

Your browser now prepares a proper request using a protocol called HTTP (or HTTPS).

This request includes:

The resource you want (like a webpage)
Your browser details
Other metadata

It’s like writing a letter with:

Address
Message
Sender info Step 5: Breaking Data into Packets

The request doesn’t travel as one big chunk.

Instead, it is broken into small packets. Each packet contains:

Part of the data
Source IP (your device)
Destination IP (server)
Sequence info

Why?
Because smaller pieces travel faster and more reliably.

Step 6: Traveling Across the Network

here we can see the forward proxy and reverse proxy
FORWARD PROXY :
where it multiple requests goes to internet.
REVERSE PROXY:
where it comes from the internet.

Your packets travel through:

Each router acts like a traffic controller, deciding:

“Where should this packet go next?”

Packets don’t always take the same path—but they all eventually reach the destination.

Step 7: Reaching the Server

Finally, the packets arrive at the server.

The server:

Reassembles the packets
Understands the request
Processes it

Step 8: Server Sends a Response

Once processed, the server sends back a response.

This response is again:

Broken into packets
Sent back through the internet
Routed back to your device

Step 9: Browser Renders the Page

Your device receives the packets and:

Reassembles them
Interprets the content
Displays it on your screen

And just like that—you see the website.

All of this typically happens in milliseconds.
A Simple Real-Life Analogy

Imagine ordering food online:

You place an order (request)
App finds the restaurant (DNS)
Order is prepared (server processing)
Delivery travels through roads (network routing)
Food reaches you (response)

Iternet works

JAYA SRI J — Mon, 23 Mar 2026 14:29:01 +0000

Hi all today I am going to write a blog o** how the internet works?**

http://10.1.34.81:8000/ here 10.1.34.81 is IP address and after the :8000/ is called port.
_..._
here one dash contains 8 bits that means 0-255 but here 0,1,255 will not appear so one dash contains 253 values.
IP TYPES
1.network port
2.host port

8its_ .8 bits.8 bits.8 bits_
here network denotes how many bits can be same or blocked and the host will change the values for every machines.

example:
10.1.34.3/24
here 10.1.34 will same for every machine and the host value will change like 3,4, ......254 etcccc.
we can use CIDR calculation for this method

FORWARD PROXY means where it goes to the internet.
REVERSE PROXY means where it comes from internet.

APPLIACTION IP :
user----> DNS query initialization----> sub resolver [local machine]
example:
www.wikipedia.org.
here last [.] represent root
org represents TLD [Top level domain]
Wikipedia represents SLD [secondary level domain]
www represents Zone file

                root [name server]
                /         |       \
               /          |        \
              /           |         \
           .org           .com     .in
          [Name server]
           /
          /
         /
    Wikipedia [name server]
       /
      /
     /
 www ------> IP

zone file :
A -----> IPV4
AAAA----> IPV6
mx-------> mail

*why we need protocol? *
Standardization
communication
IETF set the setting the conditions of internet

HTTP -----> IETF

GET----->retrieve data
POST----> creates data
PUT------> update all fields resources
PATCH-----> update partial that means update some fields
DELETE----> remove data

Merge two sorted list

JAYA SRI J — Sun, 22 Mar 2026 07:22:07 +0000

Merging Two Sorted Linked Lists

1.Merging two sorted linked lists is a fundamental problem in data structures. It is commonly used in algorithms like merge sort and appears frequently in coding interviews.

2.The goal is simple: given two sorted linked lists, combine them into one sorted linked list.
**
Understanding the Problem**

Suppose we have two sorted linked lists:

list1: 1 -> 3 -> 5
list2: 2 -> 4 -> 6

After merging, the result should be:
1 -> 2 -> 3 -> 4 -> 5 -> 6

The final list must remain sorted.

Approach Used

We use an iterative approach with a dummy node to simplify pointer handling.

The idea is:

Compare nodes from both lists
Attach the smaller node to the result
Move forward in that list
Continue until one list is exhausted
Attach the remaining nodes

Code
class Solution:
    def mergeTwoLists(self, list1, list2):
        dummy = tail = ListNode()
        while list1 and list2:
            if list1.val <= list2.val:
                tail.next, list1 = list1, list1.next
            else:
                tail.next, list2 = list2, list2.next
            tail = tail.next
        tail.next = list1 or list2
        return dummy.next

Step-by-Step Explanation

1. Create Dummy Node

dummy = tail = ListNode()

dummy is a placeholder node that helps simplify the logic
tail keeps track of the last node in the merged list

2. Traverse Both Lists

while list1 and list2:
We continue looping as long as both lists have nodes.

3. Compare Nodes
if list1.val <= list2.val:
Compare the current values of both lists
Choose the smaller value

4. Attach Node to Result
tail.next, list1 = list1, list1.next

tail.next, list2 = list2, list2.next
Attach the selected node to the merged list
Move forward in the corresponding list

5. Move Tail Pointer

tail = tail.next

Update the tail to the newly added node.

6. Attach Remaining Nodes
tail.next = list1 or list2

When one list becomes empty, attach the remaining part of the other list.

7. Return Result
return dummy.next

dummy.next points to the head of the merged list
We skip the dummy node itself
Example Walkthrough

Input:

list1 = 1 -> 2 -> 4
list2 = 1 -> 3 -> 4

Steps:

Compare 1 and 1, take one of them
Continue comparing and attaching smaller elements
Eventually merge both lists

Output:

1 -> 1 -> 2 -> 3 -> 4 -> 4
Why This Approach is Used

This method is efficient because:

It processes each node exactly once
It does not create new nodes, only rearranges pointers
The dummy node simplifies edge cases like empty lists
Time and Space Complexity

Time complexity is O(n + m), where n and m are the lengths of the two lists.

Space complexity is O(1) since no extra space is used apart from pointers.