DEV Community: Tanishka V

CA 26 - Consistency

Tanishka V — Wed, 25 Mar 2026 16:58:04 +0000

Ensuring Data Consistency in a Digital Wallet System

In this experiment, I focused on understanding how a database maintains data consistency, especially in a financial system like a digital wallet (PhonePe/GPay type). The key goal was to ensure that invalid states — such as negative account balances — are never allowed.

Initial Setup

I used the same accounts table with a constraint to prevent negative balances:

```sql id="a1b2c3"
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 INTO accounts (name, balance)
VALUES
('Alice', 1000),
('Bob', 500);




To verify:



```sql id="d4e5f6"
SELECT * FROM accounts;

Initial balances:

Alice → 1000
Bob → 500

Attempt 1: Deduct More Than Available Balance

I tried to deduct more money than Alice has:

```sql id="g7h8i9"
UPDATE accounts
SET balance = balance - 1500
WHERE name = 'Alice';




---

###  Observation

 PostgreSQL throws an error like:



```plaintext
ERROR: new row for relation "accounts" violates check constraint "accounts_balance_check"

Observation

Again, PostgreSQL prevents the update with a constraint violation.

✔ No invalid data is stored
✔ Database enforces the rule strictly

Attempt 3: Inside a Transaction

```sql id="m4n5o6"
BEGIN;

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

COMMIT;




---

###  Observation

 The transaction fails and is **automatically rolled back**

✔ No partial update
✔ Balance remains valid

---

###  Key Observations

* The database **does not allow negative balances**
* All invalid operations are **blocked immediately**
* Errors occur due to **CHECK constraint**, not transaction logic

---

###  Understanding Consistency

This demonstrates the **Consistency** property of ACID:

* Database always moves from one valid state to another
* Invalid states (like negative balance) are never allowed
* Constraints ensure rules are enforced automatically

---

###  Schema-Level vs Application-Level Rules

####  Enforced by Database (Schema Level)

* `CHECK (balance >= 0)`
* Prevents negative balances
* Automatically enforced by PostgreSQL

####  Must be Handled by Application

* Preventing overdraft before transaction
* Validating user input
* Avoiding duplicate transactions
* Business rules like daily transfer limits

---

###  Conclusion

Through this experiment, I observed that PostgreSQL strictly enforces data integrity using constraints. Even when I attempted invalid operations, the database rejected them and maintained a consistent state.

This highlights the importance of combining **database-level constraints** with **application-level logic** to build reliable systems. In real-world financial applications, both layers work together to ensure that data remains accurate, secure, and consistent at all times.

CA - 25 Atomicity

Tanishka V — Wed, 25 Mar 2026 16:54:07 +0000

Verifying Atomicity in a Digital Wallet Transaction

In this experiment, I focused on designing a secure money transfer system similar to PhonePe or GPay, where transactions must be reliable and consistent. The main objective was to verify the Atomicity property of transactions — ensuring that either all operations in a transaction are completed successfully or none of them are applied.

Initial Setup

I created the accounts table and inserted sample data:

```sql id="1k8v3n"
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 INTO accounts (name, balance)
VALUES
('Alice', 1000),
('Bob', 500);




To check the initial state:



```sql id="n8k2xq"
SELECT * FROM accounts;

Initial balances:

Alice → 1000
Bob → 500

Performing a Successful Transaction

I first implemented a correct transfer of 200 from Alice to Bob.

```sql id="x4v9pj"
BEGIN;

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

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

COMMIT;




After execution:



```sql id="l7c3zm"
SELECT * FROM accounts;

Updated balances:

Alice → 800
Bob → 700

This confirms that both operations (debit and credit) were successfully completed.

Introducing an Error After Debit

Next, I simulated a failure scenario by introducing an error after deducting money from Alice but before crediting Bob.

```sql id="d2r5qw"
BEGIN;

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

-- Intentional error (wrong column name)
UPDATE accounts
SET bal = balance + 300
WHERE name = 'Bob';

COMMIT;




 The second query fails because `bal` does not exist.

---

 Observing the Result

Now, I checked the account balances:



```sql id="f6t8yn"
SELECT * FROM accounts;

Alice’s balance remains unchanged
Bob’s balance remains unchanged

This shows that the entire transaction was rolled back automatically due to the error.

Explicit Rollback Example

To further confirm atomicity, I tested manual rollback:

```sql id="q1m7zs"
BEGIN;

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

ROLLBACK;




Checking again:



```sql id="h3v9pk"
SELECT * FROM accounts;

Key Observations

Even though the debit operation was executed, it was not permanently saved
The database prevented partial updates
Both operations (debit and credit) are treated as a single unit

Understanding Atomicity

This experiment demonstrates the Atomicity property of ACID:

A transaction is all or nothing
If any part fails → entire transaction is rolled back
No intermediate or partial changes are stored

Conclusion

Through this experiment, I verified that PostgreSQL ensures atomic transactions. Even when errors occur in the middle of a transaction, the system automatically prevents partial updates and restores the database to its previous consistent state.

This reinforces the importance of using transactions in applications like digital wallets, where accuracy and reliability are critical. Ensuring atomicity guarantees that financial operations remain safe and consistent, even in the presence of unexpected failures.

CA 27 - Isolation

Tanishka V — Wed, 25 Mar 2026 16:50:59 +0000

Simulating Concurrent Transactions and Understanding Isolation in a Digital Wallet System

In this experiment, I extended my digital wallet simulation (similar to PhonePe or GPay) to understand how databases handle concurrent transactions. In real-world systems, multiple users may try to access or modify the same data at the same time. If not handled properly, this can lead to serious issues like incorrect balances, duplicate deductions, or inconsistent data.

Initial Setup

I used the same accounts table and dummy data:

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 INTO accounts (name, balance)
VALUES
('Alice', 1000),
('Bob', 500);

To verify:

SELECT * FROM accounts;

Initial state:

Alice → 1000
Bob → 500

Simulating Concurrent Transactions

To simulate concurrency, I opened two query windows (sessions) in pgAdmin.

Session 1 (Transaction Not Committed)

BEGIN;

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

Alice’s balance becomes 700 (inside Session 1)
BUT changes are NOT committed yet

Session 2 (Concurrent Transaction)

Now, in another query window:

BEGIN;

SELECT * FROM accounts WHERE name = 'Alice';

Session 2 still sees Alice = 1000
It cannot see uncommitted changes

Trying Another Deduction in Session 2

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

This query will WAIT (lock) until Session 1 finishes
PostgreSQL prevents conflicting updates

Commit Session 1

COMMIT;

Now:

Alice → 700

Session 2 Continues

After Session 1 commits:

Session 2 resumes execution

Final result:

Alice → 200

Observations

Session 2 could not see uncommitted data → prevents Dirty Reads
PostgreSQL used locking to avoid simultaneous updates
No inconsistent or corrupted balance occurred

READ COMMITTED (Default)

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

Cannot see uncommitted data
Prevents dirty reads
May allow non-repeatable reads

REPEATABLE READ

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

✔ Data remains consistent within the transaction
✔ Prevents non-repeatable reads
✔ Stronger consistency than READ COMMITTED

SERIALIZABLE

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Highest level of isolation
Transactions behave as if executed one by one
Prevents all anomalies (dirty reads, non-repeatable reads, lost updates)

Conclusion

This experiment clearly showed how PostgreSQL handles concurrent transactions safely. Even when multiple sessions try to update the same account at the same time, the system ensures consistency using isolation levels and locking mechanisms.

Understanding isolation is crucial when building financial systems, because it ensures that:

No duplicate or conflicting transactions occur

CA - 29 Idempotency

Tanishka V — Wed, 25 Mar 2026 16:47:03 +0000

Simulating Duplicate Transactions and Understanding Their Impact

In this experiment, I simulated a real-world issue where the same transaction (money transfer) is executed multiple times. This can happen in real systems due to network retries, slow responses, or duplicate requests from users. The goal was to observe how the database behaves in such situations and whether it prevents duplicate processing.

Initial Setup

I used the same accounts table with two users: Alice and Bob.

sql id="z7k1qp"
SELECT * FROM accounts;

Initial balances:

Alice → 1000
Bob → 500

First Transaction (Valid Transfer)

I performed a transfer of 200 from Alice to Bob.

sql id="t7x2pa"
BEGIN;

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

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

COMMIT;

After execution:

Alice → 800
Bob → 700

Repeating the Same Transaction (Duplicate Execution)

Now, I executed the exact same transaction again, simulating a duplicate request.

sql id="4z91dp"
BEGIN;

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

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

COMMIT;

After running this again:

Alice → 600
Bob → 900

Executing Again (Multiple Duplicates)

Running it one more time:

sql id="j9m8vk"
BEGIN;

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

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

COMMIT;

Final balances:

Alice → 400
Bob → 1100

Observation

From this experiment, it is clear that the database does not prevent duplicate transaction execution. Each time the same query is executed, it is treated as a new transaction, and the balances are updated again.

This leads to:

Multiple deductions from the sender
Multiple credits to the receiver
Incorrect and inconsistent account balances

This is dangerous in real-world systems, especially in financial applications, where even a single duplicate transaction can cause serious issues like money loss or incorrect balances.

Real-World Solution Approaches

To prevent such problems, real-world systems implement additional safeguards:

Idempotency Keys

Each transaction is assigned a unique ID.
If the same request is received again, the system checks the ID and ignores duplicates.

Transaction Logging

Systems maintain logs of all processed transactions to avoid reprocessing.

Conclusion

Through this simulation, I understood that databases like PostgreSQL will execute every valid query they receive, without automatically checking for duplicates. This highlights the importance of designing systems that handle repeated requests carefully.

CA 28 - Durability

Tanishka V — Wed, 25 Mar 2026 16:44:05 +0000

Simulating a Digital Wallet System and Understanding Transaction Durability

As part of my database learning, I worked on simulating a simple digital wallet system, similar to applications like PhonePe or GPay. The goal was to understand how transactions are handled in a database and how systems ensure that operations like money transfers remain consistent and reliable, even in case of failures.

Creating the Accounts Table

To begin with, I created an accounts table to store user details such as ID, name, balance, and last updated timestamp. I also added a constraint to ensure that the balance never becomes negative.
sql
CREATE TABLE accounts (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
balance INT NOT NULL CHECK (balance >= 0),
last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Inserting Sample Data

Next, I inserted some dummy data to simulate users in the system.

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

To verify:

SELECT * FROM accounts;

At this stage:

Alice → 1000
Bob → 500

Performing a Money Transfer

To simulate a transaction, I transferred 200 from Alice to Bob. I used transaction control commands to ensure both operations happen together.

BEGIN;

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

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

COMMIT;

Verifying the Transaction

SELECT * FROM accounts;

After execution:

Alice → 800
Bob → 700

This confirms that the transaction was successfully committed.

Simulating a System Restart

To test durability, I simulated a system restart by disconnecting and reconnecting to the database (or restarting PostgreSQL).

After reconnecting:

SELECT * FROM accounts;

The balances remained:

Alice → 800
Bob → 700

This shows that the committed transaction persists even after a restart.

Understanding Durability

This behavior demonstrates Durability, one of the ACID properties. Once a transaction is committed, it is permanently stored in the database and cannot be lost, even in case of system failure.

PostgreSQL ensures this using mechanisms like Write-Ahead Logging (WAL), where changes are first recorded in logs before being written to the actual database.

Crash Before COMMIT

BEGIN;

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

-- Crash happens here (no COMMIT)

Result: Changes are not saved

BEGIN;

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

COMMIT;

-- Crash happens here

Testing Atomicity using ROLLBACK

I also tested what happens when a transaction is cancelled.

BEGIN;

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

ROLLBACK;

After running:

SELECT * FROM accounts;

Alice’s balance remains unchanged.

This demonstrates Atomicity, meaning either all operations in a transaction are executed or none at all.

Through this experiment, I understood how databases handle real-world financial operations securely. By using transactions (BEGIN, COMMIT, ROLLBACK), I was able to ensure consistency and reliability in money transfers.

This hands-on simulation helped me clearly understand ACID properties, especially Durability and Atomicity, and how they are essential in building systems like digital wallets where even a small inconsistency can lead to serious issues like incorrect balances or data loss.

SQL Fundamentals: Solving Real Database Queries Step by Step

Tanishka V — Tue, 24 Mar 2026 13:21:35 +0000

In this exercise, I worked on a variety of SQL queries using both the CITY and STATION (Weather Observation Station) tables. This helped me build a strong foundation in database querying and data analysis.

I began with basic queries such as retrieving all columns from the CITY table and gradually moved to more specific tasks like filtering cities based on country codes such as USA and JPN. I also learned how to extract only required fields like city names and apply conditions based on population.

In addition to city-based queries, I explored weather-related datasets using the STATION table. ~ For example, I learned how to extract only American cities with populations greater than a certain threshold and how to retrieve only specific columns like city names.

One interesting problem I solved involved retrieving a list of city names that do not start with vowels. To achieve this, I used multiple NOT LIKE conditions along with the DISTINCT keyword to ensure that duplicate entries were removed. This helped me better understand pattern matching and string filtering in SQL.

~ One key concept I practiced was eliminating duplicate data using the DISTINCT keyword. For example, I solved a problem where I calculated the difference between the total number of city entries and the number of unique city names. This gave me insight into how duplicate data can affect analysis.

Overall, this hands-on SQL practice enhanced my understanding of:

~Data retrieval using SELECT
~Filtering using WHERE conditions
~Working with multiple datasets
~Handling duplicates using DISTINCT

CA-22 : Select Queries from DVD Rental database

Tanishka V — Tue, 24 Mar 2026 09:07:40 +0000

Given task : Selecting queries from the dvd rental database using the postgre and pgadmin 4 on the macOS

I started with basic data retrieval by selecting film titles along with their rental rates. To make the output more readable, I used column aliases to rename fields like title to Movie Title and rental_rate to Rate. This small step made a big difference in how clean the results looked.

there were numerous task assigned to this specific topic which is 25 subtopics .
^ Moving forward, I worked on sorting data. For example, I retrieved a list of films sorted by rental rate in descending order. In cases where multiple films had the same rental rate, I applied a secondary sort based on the title in alphabetical order. This introduced me to multi-level sorting using the ORDER BY clause.

I also practiced sorting actor names by last name and then by first name, which reinforced my understanding of ordering data across multiple columns. Similarly, I retrieved unique values such as replacement costs, ratings, and rental durations using the DISTINCT keyword, which is very useful when dealing with repetitive data.

Another interesting part was working with film details like title and duration. By renaming the length column to Duration (min), I made the output more intuitive. I also sorted films based on their length in descending order to identify longer movies.

Additionally, I explored filtering and limiting data. For instance, I listed the 10 shortest films and retrieved the top 5 customers based on their customer IDs. These operations helped me understand how to control the size and relevance of query results.

I also worked with store and inventory data by identifying unique store IDs and determining the first rental date for each store. This gave me more exposure to handling data across different tables.

Finally, I practiced advanced sorting techniques, such as ordering films by multiple columns (like replacement cost and rental rate) and organizing customer and rental data in structured ways.

Overall, this exercise helped me strengthen my understanding of SQL concepts like:

Data retrieval using SELECT
Column aliasing
Sorting with ORDER BY
Removing duplicates using DISTINCT
Aggregation with functions like MIN()
Grouping data using GROUP BY
Limiting results with LIMIT

This hands-on practice gave me a clearer idea of how SQL is used in real-world applications to manage and analyze structured data efficiently.

ASSIGNMENT 20

Tanishka V — Mon, 23 Mar 2026 05:10:28 +0000

Search in a Rotated Sorted Array (O(log n) Binary Search)

Searching in a rotated array might look tricky at first — but with the right approach, it becomes elegant and efficient 🔥

Let’s break it down 👇

📌 Problem Statement

You are given a sorted array that has been rotated at some unknown index.

👉 Your task is to find the index of a target element.

⚠️ Constraints:
All elements are distinct
Must run in O(log n) time
If target not found → return -1
🧪 Examples
Example 1
Input: nums = [4,5,6,7,0,1,2], target = 0
Output: 4
Example 2
Input: nums = [4,5,6,7,0,1,2], target = 3
Output: -1
Example 3
Input: nums = [1], target = 0
Output: -1
💡 Key Insight

Even though the array is rotated, one half is always sorted.

👉 At any point:

Either the left half is sorted
Or the right half is sorted

We use this property to apply Binary Search.

🧠 Algorithm Strategy
Find mid
Check which half is sorted:
If nums[low] <= nums[mid] → Left half is sorted
Else → Right half is sorted
Decide where target lies:
If target is in sorted half → search there
Else → search other half
🔄 Step-by-Step Logic
Case 1: Left Half is Sorted
nums[low] <= nums[mid]

If:

nums[low] <= target < nums[mid]

→ Search left

Else → Search right
Case 2: Right Half is Sorted
nums[mid] < nums[high]

If:

nums[mid] < target <= nums[high]

→ Search right

Else → Search left
💻 Python Implementation
def search(nums, target):
low, high = 0, len(nums) - 1

while low <= high:

    mid = (low + high) // 2

if nums[mid] == target:
    return mid

# Left half sorted
if nums[low] &lt;= nums[mid]:
    if nums[low] &lt;= target &lt; nums[mid]:
        high = mid - 1
    else:
        low = mid + 1

# Right half sorted
else:
    if nums[mid] &lt; target &lt;= nums[high]:
        low = mid + 1
    else:
        high = mid - 1



return -1

Example usage

nums = [4,5,6,7,0,1,2]
target = 0
print(search(nums, target))
🧾 Output
4
🔍 Dry Run (Quick Insight)

For:

[4,5,6,7,0,1,2], target = 0
Mid = 7 → left sorted
Target not in left → move right
Eventually find 0 at index 4
⚡ Complexity Analysis
Metric Value
Time Complexity O(log n)
Space Complexity O(1)

ASSIGNMENT 19

Tanishka V — Mon, 23 Mar 2026 05:09:09 +0000

Find First and Last Occurrence in a Sorted Array (Binary Search)

Searching efficiently in a sorted array is a must-know skill.
Let’s solve a classic problem using Binary Search 👇

📌 Problem Statement

Given a sorted array arr, find the first and last occurrence of a given element x.

⚠️ Conditions:
If x is not found → return [-1, -1]
Must be efficient (better than linear search)
🧪 Examples
Example 1
Input: arr = [1, 3, 5, 5, 5, 5, 67, 123, 125], x = 5
Output: [2, 5]
Example 2
Input: arr = [1, 3, 5, 5, 5, 5, 7, 123, 125], x = 7
Output: [6, 6]
💡 Optimal Approach: Modified Binary Search

Instead of scanning the array, we use Binary Search twice:

Find first occurrence
Find last occurrence
🧠 Key Idea
For first occurrence:
Move left even after finding x
For last occurrence:
Move right even after finding x
🔄 Algorithm Steps
🔍 First Occurrence
If arr[mid] == x:
Store index
Move left (high = mid - 1)
🔍 Last Occurrence
If arr[mid] == x:
Store index
Move right (low = mid + 1)
💻 Python Implementation
def find_first(arr, x):
low, high = 0, len(arr) - 1
first = -1

while low <= high:
    mid = (low + high) // 2

    if arr[mid] == x:
        first = mid
        high = mid - 1
    elif arr[mid] < x:
        low = mid + 1
    else:
        high = mid - 1

return first

def find_last(arr, x):
low, high = 0, len(arr) - 1
last = -1

while low <= high:
    mid = (low + high) // 2

    if arr[mid] == x:
        last = mid
        low = mid + 1
    elif arr[mid] < x:
        low = mid + 1
    else:
        high = mid - 1

return last

def find_occurrences(arr, x):
return [find_first(arr, x), find_last(arr, x)]

Example usage

arr = [1, 3, 5, 5, 5, 5, 67, 123, 125]
x = 5
print(find_occurrences(arr, x))
🧾 Output
[2, 5]
🔍 Dry Run (Quick Insight)

For:

[1, 3, 5, 5, 5, 5, 67]
First occurrence → keep moving left
Last occurrence → keep moving right
⚡ Complexity Analysis
Metric Value
Time Complexity O(log n)
Space Complexity O(1)

🏁 Conclusion

This problem shows how powerful Binary Search can be when slightly modified.

ASSIGNMENT 18

Tanishka V — Mon, 23 Mar 2026 05:05:27 +0000

📌 Problem Statement

Given a sorted integer array nums (in non-decreasing order), return a new array of the squares of each number, also sorted in non-decreasing order.

🧪 Examples

Example 1

Input:  [-4, -1, 0, 3, 10]
Output: [0, 1, 9, 16, 100]

Example 2

Input:  [-7, -3, 2, 3, 11]
Output: [4, 9, 9, 49, 121]

❗ Why Not Just Square & Sort?

A simple solution:

square → sort

But that takes:

⏱ O(n log n) time

👉 We can do better: O(n)

💡 Optimal Approach: Two-Pointer Technique

🧠 Key Insight

The array is sorted, BUT contains negative numbers
Squaring negatives makes them positive → order breaks

👉 The largest square will always come from:

Either the leftmost element OR
The rightmost element

🔄 Algorithm Steps

Initialize:

   left = 0
   right = n - 1

Create result array of size n
Fill from end to start
Compare:

abs(nums[left]) vs abs(nums[right])
1. Place the larger square at the end

💻 Python Implementation

```python id="code1"
def sorted_squares(nums):
n = len(nums)
result = [0] * n

left = 0
right = n - 1
pos = n - 1

while left <= right:
    if abs(nums[left]) > abs(nums[right]):
        result[pos] = nums[left] ** 2
        left += 1
    else:
        result[pos] = nums[right] ** 2
        right -= 1
    pos -= 1

return result

Example usage

nums = [-4, -1, 0, 3, 10]
print(sorted_squares(nums))




---

## 🧾 Output



```id="out1"
[0, 1, 9, 16, 100]

🔍 Dry Run (Quick Insight)

For:

[-4, -1, 0, 3, 10]

Compare |-4| and |10|
Place 100 at end
Move inward and repeat

⚡ Complexity Analysis

Metric	Value
Time Complexity	O(n)
Space Complexity	O(n)

🎯 Key Takeaways

Sorting after squaring is not optimal ❌
Use two-pointer technique for O(n) ✅
Works because input array is already sorted 🔥

🏁 Conclusion

This problem is a great example of how understanding the data structure can lead to optimized solutions.

ASSIGNMENT 13

Tanishka V — Mon, 23 Mar 2026 05:03:37 +0000

Move All Zeros to the End (In-Place & Stable)

Rearranging arrays efficiently is a key skill in coding interviews.
Let’s solve a classic problem: moving all zeros to the end while maintaining order

Problem Statement

Given an integer array nums, move all 0s to the end of the array.

Constraints:
Maintain the relative order of non-zero elements
Perform the operation in-place
Do not create a copy of the array .

Examples:
Example 1
Input: [0, 1, 0, 3, 12]
Output: [1, 3, 12, 0, 0]
Example 2
Input: [0]
Output: [0]
Optimal Approach: Two-Pointer Technique

We use a two-pointer approach to solve this efficiently.

i → scans the array
j → tracks position to place next non-zero element

-Move all non-zero elements forward
-Fill remaining positions with 0s

This ensures:

Order is preserved .
No extra space is used .

~ Algorithm Steps ;

Initialize j = 0
Traverse array using i
If nums[i] != 0:
Swap nums[i] with nums[j]
Increment j
Continue till end

Python Implementation
def move_zeros(nums):
j = 0 # position for next non-zero

for i in range(len(nums)):

    if nums[i] != 0:

        nums[i], nums[j] = nums[j], nums[i]

        j += 1

Example usage

nums = [0, 1, 0, 3, 12]
move_zeros(nums)
print(nums)

~ Key Takeaways :
Uses two-pointer technique
Maintains relative order (stable)
Works in-place
Very common interview problem

ASSIGNMENT 12

Tanishka V — Mon, 23 Mar 2026 05:00:21 +0000

Next Permutation (In-Place & Optimal Solution)

Understanding permutations is key in many algorithmic problems.
Let’s solve a classic one: finding the next lexicographically greater permutation

Given an array of integers nums, rearrange it into the next lexicographically greater permutation.

Constraints:
-Must be done in-place
-Use only constant extra memory
-If no greater permutation exists → return the lowest possible order (sorted ascending)

Example 1
Input: [1, 2, 3]
Output: [1, 3, 2]
Example 2
Input: [3, 2, 1]
Output: [1, 2, 3]
Example 3
Input: [1, 1, 5]
Output: [1, 5, 1]

We want the next bigger arrangement, but just slightly bigger — not the maximum.

Find a place where the order breaks
Swap intelligently
Rearrange the remaining part

Step-by-Step Algorithm

Step 1: Find the Breakpoint

Traverse from right and find the first index i such that:

nums[i] < nums[i + 1]

If No Breakpoint Found

The array is in descending order (largest permutation)

Simply reverse it:

[3,2,1] → [1,2,3]
Step 2: Find Next Greater Element

From the right side, find an element nums[j] such that:

nums[j] > nums[i]
Step 3: Swap

Swap:

nums[i] ↔ nums[j]
Step 4: Reverse the Right Half

Reverse elements from:

i + 1 → end

This ensures the smallest possible order after the swap

Python Implementation
def next_permutation(nums):
n = len(nums)

# Step 1: Find breakpoint

i = n - 2

while i >= 0 and nums[i] >= nums[i + 1]:

    i -= 1

  
  
  Step 2: If breakpoint exists


if i >= 0:

    j = n - 1

    while nums[j] <= nums[i]:

        j -= 1

    nums[i], nums[j] = nums[j], nums[i]

  
  
  Step 3: Reverse the suffix


left, right = i + 1, n - 1

while left < right:

    nums[left], nums[right] = nums[right], nums[left]

    left += 1

    right -= 1

Example usage

nums = [1, 2, 3]
next_permutation(nums)
print(nums)