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.

AWS (Amazon Web Services), Microsoft Azure, and Google Cloud Platform (GCP)

 

AWS (Amazon Web Services), Microsoft Azure, and Google Cloud Platform (GCP) are the top three cloud providers.

All offer similar #core #services, but each excels in different #areas.

#Market #Position

#AWS: Market #leader, first mover (launched 2006), widest adoption
#Azure: Strong second, dominant in #enterprises and Microsoft #ecosystems
#GCP: Third largest, popular for #data, #analytics, and cloud‑native workloads

AWS
Largest #service #portfolio (200+ services)
Most mature and feature‑rich #platform
Excellent #global coverage
Strong #startup and #SaaS #adoption
Broad #open‑source support

Azure
Best #hybrid #cloud capabilities (#Azure Arc, Stack)
Seamless #Microsoft integration (Windows, AD, Office 365)
Strong #enterprise and #compliance support
Ideal for .NET and SQL Server workloads

GCP
Best data & analytics (#BigQuery, #Dataflow)
Strong AI/ML #leadership (Vertex AI, TensorFlow)
Best-in-class #Kubernetes experience (GKE)
Simple pricing and clean UI
Strong networking #performance