AI: PROTOCOLS THEN & PROTOCOLS NOW

 

We spent 30 years simplifying distributed systems.

TCP/IP.
HTTP.
TLS.

Then we added agents.

Now the architecture diagram looks like this:

MCP → agent ↔ tools/data
A2A → agent ↔ agent
AG-UI → agent ↔ user
A2UI → agent → UI
ANP → agent ↔ agent network
AP2 / UCP → agentic commerce & payments
AGENTS.md / SKILL.md → instructions & capabilities

And no, they're not all protocols.

We are building a new distributed-computing stack…and simultaneously inventing the documentation needed to understand the stack.

The irony?
The agent doesn't just need tools.

It needs:

a protocol,
an identity,
a skill,
a policy,
an interface,
another agent,
and apparently… an ADR explaining all of it.

 

𝗗𝗲𝘃𝗢𝗽𝘀 𝗯𝗲𝗴𝗶𝗻𝗻𝗲𝗿𝘀 𝘀𝗸𝗶𝗽 𝘁𝗵𝗲𝘀𝗲 𝗳𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀

 

Most beginners jump straight into Docker, Kubernetes, or Terraform... But without understanding what DevOps really is, learning tools becomes much harder.

Here is the handwritten DevOps notes—to make learning simple, visual, and interview-friendly.

𝗜𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗶𝘀 𝟴-𝗽𝗮𝗴𝗲 𝗴𝘂𝗶𝗱𝗲:
What is DevOps? (Definition & Introduction)
DevOps Architecture & Working Flow
Complete DevOps Lifecycle
Benefits with Real-World Examples
Essential DevOps Tools Overview
CI/CD Pipeline Explained Simply
20+ DevOps Interview Questions & Answers
One-Page Cheat Sheet + Memory Tricks

𝗧𝗵𝗲𝘀𝗲 𝗻𝗼𝘁𝗲𝘀 𝗮𝗿𝗲 𝗽𝗲𝗿𝗳𝗲𝗰𝘁 𝗳𝗼𝗿:
DevOps Beginners
College Students
Job Seekers
Interview Preparation
Quick Revision Before Interviews

 

Terraform Project

 

#Terraform Project file structure explained in a very easy way to understand.

You can also download the best DevOps, Cloud & SRE interview preparation resources using below link.

DevOps 22 Tools: https://lnkd.in/dTkDf9-4

All DevOps Resources: https://lnkd.in/dMGrMpHM

 

Bonding is an operating-system feature that provides NIC redundancy and sometimes load balancing by combining multiple interfaces into a single logical interface. Oracle RAC sees only one IP address on the bonded interface. 

HAIP, introduced in Oracle RAC 11.2.0.2, operates at the Grid Infrastructure layer and provides Oracle-aware load balancing and failover across multiple private interconnects. In Exadata, HAIP is preferred because it allows RAC Cache Fusion traffic to use both InfiniBand fabrics simultaneously while automatically handling NIC or switch failures.

Linux bonding supports multiple modes, including active-standby, active-backup and active-active modes such as round-robin and LACP. However, in Oracle RAC and Exadata environments, HAIP is preferred because it provides Oracle-aware load balancing and failover across multiple interconnect interfaces, allowing Cache Fusion traffic to use all available private networks and automatically recover from NIC or switch failures

HAIP vs Bonding

Feature	Bonding	HAIP
Layer	OS Layer (Linux)	Oracle Grid Infrastructure Layer
Introduced By	Linux	Oracle RAC 11.2.0.2
Redundancy	Yes	Yes
Load Balancing	Depends on bonding mode	Yes
Active-Active	Depends on mode	Yes
Active-Standby	Possible	No
Oracle Aware	No	Yes
Automatic NIC Failover	Yes	Yes
Automatic Switch Failover	Yes	Yes
Multiple Interconnect Utilization	Limited	Excellent
RAC Recommended	Older approach	Preferred approach

Why RAC HAIP Instead of Bonding?

- Even if bonding is active-active: Oracle RAC sees      

              ONE interface

              ONE IP

ib0 & ib1 ---> bond0 ---->192.168.10.11

- HAIP gives RAC visibility into multiple interconnects:

ib0 ----> 172.16.1.x

ib1 ----> 172.16.2.x

HAIP1 -> 169.254.x.x

HAIP2 -> 169.254.y.y

Benefits:

• Oracle-managed failover
• Oracle-managed load balancing
• Multiple active interconnect paths
• Better Cache Fusion distribution

Exadata Example: 

Both fabrics are utilized simultaneously.

                           ---------->ib0 ---->Switch A 

                           |

Cache Fusion ---> 

                            |

                            --------->ib1 -----> Switch B  

If Switch A fails:

   HAIP on ib0  ---> moves to -> ib1 

ORACLE CLOUD INFRASTRUTURE (OCI) Services

 

Oracle Cloud Infrastructure (OCI) Services Overview — Key Areas Every Cloud Engineer Should Know

Key OCI Service Domains:

- Compute: VM Instances (Intel, AMD, Ampere), Bare Metal Instances, Container Engine for Kubernetes (OKE), OCI Functions

- Storage: Object Storage, Block Volumes, File Storage, Archive Storage

- Networking: Virtual Cloud Network (VCN), Load Balancer (Public/Private), Dynamic Routing Gateway (DRG), FastConnect, OCI DNS

- Databases: OCI Database (Exadata Cloud Service, Bare Metal DB, VM DB), Autonomous Database (ATP, ADW), OCI MySQL, OCI PostgreSQL

- Security: Identity & Access Management (IAM), OCI Vault (Key Management), Cloud Guard, Vulnerability Scanning

- Analytics & AI: OCI Data Science, OCI AI Services (Language, Vision, Speech), OCI Analytics Cloud, Data Integration

- DevOps & Management: OCI DevOps, Logging, Monitoring Service, Resource Manager (Terraform), OCI Automation

Key Takeaway:
Understanding these core OCI services is essential for designing scalable, high-performance, and production-ready cloud environments tailored for enterprise workloads. This post reflects my continuous learning in Oracle Cloud Architecture and infrastructure.

How does Amazon make sure it does not sell the same item 10 lakh times?

 10 lakh people hit "Buy Now" at the exact same time during a flash sale. Only 2 units are left.

How does Amazon make sure it does not sell the same item 10 lakh times? I’m a Backend engineer and I love these types of questions; let’s break it down.

One simple answer that comes to mind is:  "Just update the database." But this falls apart the moment traffic spikes.

The problem here is not inventory storage. It is concurrent reservation under extreme contention. Here is the high-level way to think about it:

1. Fast gate in front of the DB

You do not want all 10 lakh requests hammering the database. So systems often keep a fast in-memory inventory counter, usually in something like Redis.

If stock = 2, only the first 2 atomic decrements succeed.
Everyone else gets rejected immediately.

That gives you a very cheap first filter.

2. Atomic decrement matters

This has to happen as one indivisible step.

Not:
- read stock
- subtract 1
- write back

Because 1,000 servers doing that in parallel will oversell instantly.
You need one atomic operation so only 2 requests can win.

3. Soft hold, not instant final sale

Even after a user "wins" the decrement, the item is usually not sold forever yet. It is placed on a temporary hold for a short time window.

Why?

Because users abandon carts.
Payments fail.
Sessions die.

So the system reserves inventory briefly, then releases it if checkout does not complete.

4. Database is still the final authority

Redis is the speed layer.
The database is the truth layer.

At checkout or order confirmation, the DB uses optimistic or pessimistic locking to make sure the final stock transition is valid. That is your last line of defense.

5. Why both layers exist

If you only use the DB:
- too much lock contention
- poor latency
- system melts during flash sales

If you only use Redis:
- faster, but risky if you skip durable confirmation

So the usual pattern is:

Redis for fast distributed reservation
DB for final correctness

If you want more help with LLD or HLD, check out these links:

1. HLD: https://lnkd.in/eAvAtm2K
2. LLD: https://lnkd.in/e3T6gxaA

Some important points to keep in mind:

1. Redis persistence matters for recovery

If Redis holds the inventory counter and it crashes right after selling the last two units, you could lose that state. When Redis comes back up, it might think stock is still 2, and you risk overselling.

To avoid this, use Redis with AOF (append-only file) persistence or a Redis Cluster with replication. Even then, treat Redis as a fast gate, not the final ledger.

2. The hold window needs careful sizing

If you hold inventory for too long, genuine buyers get "sold out" messages while abandoned carts lock up stock. If you hold it for too short, users start checkout, but inventory gets released before they finish.

Common approach: start with a short hold (5–10 minutes), then extend if the user is actively progressing through checkout.