Forem: Minindu Rupasinghe

Advent of Code 2025 - Day 5: Cafeteria

Minindu Rupasinghe — Wed, 10 Dec 2025 16:48:19 +0000

The Problem

The Elves have a database with fresh ingredient ID ranges and need to check their inventory. Part 1 asks: given specific ingredient IDs, how many are fresh (fall within the ranges)? Part 2 reveals the real question: how many total IDs do these ranges cover?

Example:

Ranges: 3-5, 10-14, 16-20, 12-18
IDs to check: 1, 5, 8, 11, 17, 32
Fresh IDs from list: 3 (IDs 5, 11, 17)
Total IDs covered by ranges: 14

My Approach

When I saw overlapping ranges in Part 1, I knew Part 2 would likely ask about the ranges themselves. A brute-force check works for Part 1, but counting all IDs with overlaps is messy. So I merged the ranges upfront; if ranges overlap, combine them into one. This made Part 2 trivial.

Merging Ranges

Sort ranges and merge overlapping intervals. Ranges like 10-14 and 12-18 become 10-18.

fn merge_ranges(fresh_ranges: &mut Vec<(u64, u64)>) -> Vec<(u64, u64)> {
    // Sort ranges in descending order by start value
    // This allows us to pop from the end (smallest start) for processing
    fresh_ranges.sort_by(|a, b| b.0.cmp(&a.0));
    let mut merged_ranges: Vec<(u64, u64)> = Vec::new();

    while fresh_ranges.len() > 0 {
        // Pop the range with the smallest start value
        let mut range = fresh_ranges.pop().unwrap();

        if fresh_ranges.len() == 0 {
            // Last range, just add it
            merged_ranges.push(range);
        } else {
            // Check if the current range overlaps with the next range
            // Ranges overlap if current end >= next start
            if range.1 >= fresh_ranges.last().unwrap().0 {
                // Merge: pop the next range and extend the current range's end
                let another = fresh_ranges.pop().unwrap();
                range.1 = range.1.max(another.1);
                // Push merged range back to continue merging
                fresh_ranges.push(range);
            } else {
                // No overlap, add to merged list
                merged_ranges.push(range);
            }
        }
    }
    merged_ranges
}

Part 1: Check Specific IDs

Check if each ingredient falls within any merged range.

fn fresh_ingredients(fresh_ranges: &Vec<(u64, u64)>, ingredients: &Vec<u64>) -> u32 {
    let mut count = 0;
    for ingredient in ingredients {
        for range in fresh_ranges {
            if range.0 <= *ingredient && range.1 >= *ingredient {
                count += 1;
                break;
            }
        }
    }
    count
}

Part 2: Count All Fresh IDs

Sum the size of each merged range.

fn all_fresh_ingredients(fresh_ranges: &Vec<(u64, u64)>) -> u64 {
    let mut count = 0;
    for range in fresh_ranges {
        count += range.1 - range.0 + 1;
    }
    count
}

Why This Works

Merging ranges eliminates overlaps, making Part 2 a simple sum instead of complex overlap handling.

Practice interval merging: LeetCode Merge Intervals

Full Solution

You can find my complete solution, including input parsing and testing, on GitHub:

View Full Solution on GitHub

Have you solved this puzzle differently? I'd love to hear about alternative approaches in the comments!

Advent of Code 2025 - Day 4: Paper Roll Removal

Minindu Rupasinghe — Tue, 09 Dec 2025 09:41:04 +0000

Day 4 was about helping elves clear paper rolls so forklifts could break through a wall. The twist? Forklifts can only grab rolls with fewer than 4 neighbors.

The Problem

Given a grid of paper rolls (@) and empty spaces (.):

..@@.@@@@.
@@@.@.@.@@
@@@@@.@.@@
@.@@@@..@.
@@.@@@@.@@
.@@@@@@@.@
.@.@.@.@@@
@.@@@.@@@@
.@@@@@@@@.
@.@.@@@.@.

Part 1: Count rolls that have fewer than 4 neighbors (checking all 8 surrounding cells).

Part 2: Remove accessible rolls. Once removed, previously blocked rolls might become accessible. Continue until nothing remains to be removed.

Part 1: Counting Accessible Rolls

I parsed the grid (. = 0, @ = 1) and counted neighbors for each roll. The only trick was keeping the 8 direction checks clean:

const DIRECTIONS: [(i32, i32); 8] = [
    (1, 0), (0, 1), (1, 1), (-1, 0),
    (0, -1), (-1, -1), (-1, 1), (1, -1),
];

fn liftable_roll_papers(grid: &Vec<Vec<i32>>) -> i32 {
    let n = grid.len() as i32;
    let m = grid[0].len() as i32;
    let mut liftable = 0;

    for x in 0..n {
        for y in 0..m {
            if grid[x as usize][y as usize] == 1 {
                let mut rolls = 0;
                for direction in DIRECTIONS {
                    let x_new = x + direction.0;
                    let y_new = y + direction.1;
                    if x_new >= 0 && x_new < n && y_new >= 0 && y_new < m {
                        if grid[x_new as usize][y_new as usize] == 1 {
                            rolls += 1;
                        }
                    }
                }
                if rolls < 4 {
                    liftable += 1;
                }
            }
        }
    }
    liftable
}

Loop through the grid, check all 8 neighbors, and count if there are fewer than 4. Nothing fancy.

Example

For the sample grid, rolls at the edges or in sparse areas have fewer neighbors:

..xx.xx@x.   <- These x marks show accessible rolls
x@@.@.@.@@
@@@@@.x.@@
@.@@@@..@.
x@.@@@@.@x
.@@@@@@@.@
.@.@.@.@@@
x.@@@.@@@@
.@@@@@@@@.
x.x.@@@.x.

Part 2: The Chain Reaction

This is where it got interesting. Removing rolls creates a domino effect; rolls that were surrounded might suddenly become accessible.

I took the straightforward approach: scan the entire grid, remove what I could, and repeat until no changes were made.

fn removable_roll_papers(grid: &mut Vec<Vec<i32>>) -> i32 {
    let n = grid.len() as i32;
    let m = grid[0].len() as i32;
    let mut removed = -1;
    let mut total_removed = 0;

    while removed != 0 {
        removed = 0;
        for x in 0..n {
            for y in 0..m {
                if grid[x as usize][y as usize] == 1 {
                    let mut rolls = 0;
                    for direction in DIRECTIONS {
                        let x_new = x + direction.0;
                        let y_new = y + direction.1;
                        if x_new >= 0 && x_new < n && y_new >= 0 && y_new < m {
                            if grid[x_new as usize][y_new as usize] == 1 {
                                rolls += 1;
                            }
                        }
                    }
                    if rolls < 4 {
                        grid[x as usize][y as usize] = 0;
                        removed += 1;
                    }
                }
            }
        }
        total_removed += removed;
    }
    total_removed
}

The loop tracks removed each pass. When it hits zero, we're done.

How It Works

Starting with the same example grid:

Pass 1: Remove 13 rolls (the initially accessible ones)

..xx.xx@x.
x@@.@.@.@@
@@@@@.x.@@
@.@@@@..@.
x@.@@@@.@x
.@@@@@@@.@
.@.@.@.@@@
x.@@@.@@@@
.@@@@@@@@.
x.x.@@@.x.

Pass 2: More rolls become accessible as their neighbors disappear, remove 12 more

.......x..
.@@.x.x.@x
x@@@@...@@
x.@@@@..x.
.@.@@@@.x.
.x@@@@@@.x
.x.@.@.@@@
..@@@.@@@@
.x@@@@@@@.
....@@@...

Continue until nothing changes.

Why This Works

Could I have used a queue to track "maybe accessible" cells? Sure. Could I have been smarter about which cells to recheck? Probably.

But here's the thing: the grid isn't massive, and the number of passes needed is small. Rolls get removed in waves, and the whole thing converges fast. The simple "scan everything until stable" approach was easier to write and easier to debug than trying to be clever.

I mutated the grid in-place because tracking a separate "removed" set felt unnecessary. The grid changes, the code reflects that. Done.

Full Solution

You can find my complete solution, including input parsing and testing, on GitHub:

View Full Solution on GitHub

Have you solved this puzzle differently? I'd love to hear about alternative approaches in the comments!

Advent of Code 2025 - Day 3: Maximizing Battery Joltage

Minindu Rupasinghe — Mon, 08 Dec 2025 19:23:45 +0000

I recently tackled Day 3 of Advent of Code 2025, and it turned out to be an interesting optimization problem disguised as a battery puzzle. The premise was simple: help restore power to an offline escalator by maximizing the joltage output from battery banks. But the solution required some clever thinking about greedy algorithms and optimization strategies.

Understanding the Problem

We're given multiple banks of batteries, where each battery is labeled with a joltage rating from 1 to 9. The puzzle input looks something like this:

987654321111111
811111111111119
234234234234278
818181911112111

Each line represents a battery bank, and we need to select specific batteries to form numbers that maximize joltage output.

Part 1: Select exactly 2 batteries from each bank to create the largest possible two-digit number. The batteries must maintain their original order (no rearranging).

Part 2: Crank it up to 12 batteries per bank to create twelve-digit numbers.

The final answer is the sum of maximum joltages across all banks.

Part 1: The Two-Battery Problem

Initial Thoughts

My first reaction was straightforward: iterate through all possible pairs of batteries and pick the maximum. But with potentially long battery banks, this O(n²) approach felt inefficient. There had to be a better way.

The Key Insight

Then it hit me: for a two-digit number, we want the largest digit as far left as possible. The tens place contributes 10x more than the ones place, so maximizing the left digit is crucial.

This led me to think about the problem differently. For any split point in the battery bank, I could form a two-digit number using:

The maximum digit from the left section (tens place)
The maximum digit from the right section (ones place)

The Solution

fn compute_joltage_1(battery_banks: &Vec<Vec<u32>>) -> u64 {
    let mut total_joltage = 0;

    for battery_bank in battery_banks {
        let n = battery_bank.len();
        let mut pre_max = vec![0; n];
        let mut post_max = vec![0; n];

        // Precompute maximum from left
        pre_max[0] = battery_bank[0];
        for i in 1..n {
            pre_max[i] = max(pre_max[i-1], battery_bank[i]);
        }

        // Precompute maximum from right
        post_max[n-1] = battery_bank[n-1];
        for i in 1..n {
            post_max[n-i-1] = max(post_max[n-i], battery_bank[n-i-1]);
        }

        // Find the best split point
        let mut joltage = 0;
        for i in 0..n-1 {
            joltage = max(joltage, 10 * pre_max[i] as u64 + post_max[i+1] as u64);
        }

        total_joltage += joltage;
    }

    total_joltage
}

The strategy:

Build a pre_max array where pre_max[i] stores the maximum battery value from index 0 to i
Build a post_max array where post_max[i] stores the maximum battery value from index i to the end
For each possible split point, compute the two-digit number and track the maximum

This reduces the complexity to O(n) with a single pass to build the arrays and another to find the optimal split. Much better!

Example Walkthrough

For the bank 987654321111111:

pre_max = [9,9,9,9,9,9,9,9,9,9,9,9,9,9,9]
post_max = [9,8,7,6,5,4,3,2,1,1,1,1,1,1,1]
Best split: position 0, giving us 9 * 10 + 8 = 98

Part 2: The Twelve-Battery Problem

The Challenge Escalates

Now we need to select 12 batteries instead of 2. The search space explodes exponentially, making brute force completely impractical. I needed a different approach.

Greedy Strategy

The solution came from recognizing that positional value matters enormously. A 9 in the leftmost position contributes 9 × 10¹¹, while a 9 in the rightmost position only contributes 9 × 10⁰. This massive difference means we should greedily select the largest digit possible for each position, working left to right.

But there's a constraint: we need to ensure we can still select enough batteries for the remaining positions.

The Solution

fn compute_joltage_2(battery_banks: &Vec<Vec<u32>>) -> u64 {
    let mut total_joltage: u64 = 0;

    for battery_bank in battery_banks {
        let n: usize = battery_bank.len();
        let mut dist: usize = n - 11;  // Initial search window end
        let mut pos: usize = 0;         // Current search start
        let mut joltage: u64 = 0;

        // Select 12 digits from most to least significant
        for i in (1..=12).rev() {
            let mut digit: u32 = 0;
            let end = dist;
            let start = pos;

            // Find the largest digit in the valid range
            for j in start..end {
                if battery_bank[j] > digit {
                    pos = j;
                    digit = battery_bank[j];
                }
            }

            // Add this digit's contribution
            joltage += digit as u64 * 10u64.pow((i as u32) - 1);
            pos += 1;  // Next search starts after this position
            dist += 1; // Expand search window
        }

        total_joltage += joltage;
    }

    total_joltage
}

How the Search Window Works

The clever part is managing the sliding search window:

First digit (position 12): Search from index 0 to n-11. This ensures we leave at least 11 batteries for the remaining positions.
After selecting a digit at position pos:
- Next search starts at pos + 1 (can't reuse batteries)
- Search window expands by 1 (we need one fewer remaining battery)
Continue until all 12 digits are selected

Example Walkthrough

For the bank 987654321111111:

Position 12: Search [0, 4], pick 9 at index 0
Position 11: Search [1, 5], pick 8 at index 1
Position 10: Search [2, 6], pick 7 at index 2
...and so on

Result: 987654321111 (skipping the last few 1s)

Why This Greedy Approach Works

The greedy algorithm is optimal because of the exponential positional value difference. Consider this:

Moving from 8 to 9 in position 12: gains 1 × 10¹¹ = 100,000,000,000
Maximizing ALL remaining 11 positions with 9s: gains at most 9 × (10¹⁰ + ... + 10⁰) ≈ 10¹¹

The leftmost position always dominates! This means locally optimal choices (picking the largest digit available for each position) lead to the globally optimal solution.

Performance

Both solutions run in O(n × m) time, where n is the number of battery banks and m is the average bank length. The precomputation in Part 1 and the constrained greedy search in Part 2 keep everything efficient even for large inputs.

Key Takeaways

Precomputation saves time: Building auxiliary arrays can turn O(n²) problems into O(n) solutions
Greedy works when position matters: Problems with exponential positional value often yield to greedy strategies
Constraints guide the solution: The "must leave enough batteries" constraint was the key to implementing the greedy approach correctly

This puzzle reminded me that recognizing problem structure often beats brute force. Sometimes the best optimization is changing your perspective on the problem itself.

Full Solution

You can find my complete solution, including input parsing and testing, on GitHub:

View Full Solution on GitHub

Have you solved this puzzle differently? I'd love to hear about alternative approaches in the comments!

Advent of Code 2025 Day 2: Gift Shop 🎁

Minindu Rupasinghe — Sun, 07 Dec 2025 16:14:03 +0000

The Problem

We need to find "invalid" product IDs in given ranges. An ID is invalid if it's made of a repeated digit sequence.

Part 1: Find IDs repeated exactly twice (e.g., 1212, 345345)

Part 2: Find IDs repeated at least twice (e.g., 123123, 1111, 12121212)

Part 1: The Easy One

Part 1 was straightforward. For each number in the range:

Convert to string
Check if length is even
Split in half and compare

fn invalid_id_sum1(ranges: Vec<(u128, u128)>) -> u128 {
    let mut id_sum: u128 = 0;
    for (start, end) in ranges.iter() {
        for i in *start..*end+1 {
            let s = i.to_string();
            if s.len() % 2 != 0 {
                continue;
            }
            let (a, b) = s.split_at(s.len() / 2);
            let x: u128 = a.parse().expect("Expected a number");
            let y: u128 = b.parse().expect("Expected a number");
            if x == y {
                id_sum += i;
            }
        }
    }
    id_sum
}

Simple: if both halves match, it's invalid.

Part 2: The Tricky One

Part 2 got me thinking. Numbers can repeat 2, 3, 4+ times. My first approach only checked one specific split, which failed for cases like:

12121212 (should be 1212|1212, not something else)
12211221 (should be 1221|1221)

The fix: Try all possible split counts from 2 up to the maximum.

Here's my approach:

fn invalid_id_sum2(ranges: Vec<(u128, u128)>) -> u128 {
    let mut id_sum: u128 = 0;
    for (start, end) in ranges.iter() {
        for i in *start..*end+1 {
            let s = i.to_string();
            let mut map: [usize; 10] = [0; 10];
            for c in s.chars() {
                if let Some(digit) = c.to_digit(10) {
                    map[digit as usize] += 1;
                }
            }
            let mut splits: usize= 1000;

            for j in 0..10 {
                if map[j] != 0 {
                    splits = min(splits, map[j]);
                }
            }
            for split in 2..splits+1 {
                let len = s.len() / split ;
                let mut parts: Vec<i128> = Vec::new();
                let mut start = 0;

                for _ in 0..split {
                    let end = start + len;
                    parts.push((&s[start..end]).parse().expect("Expected a number"));
                    start = end;
                }
                if start < s.len() {
                    parts.push((&s[start..]).parse().expect("Expected a number"));
                }
                let num = parts[0];
                let mut invalid = true;
                for x in 1..parts.len() {
                    if num != parts[x] {
                        invalid = false;
                    }
                }
                if parts.len() == 1 {
                    invalid = false;
                }
                if invalid {
                    id_sum += i;
                    break
                }
            }
        }
    }
    id_sum
}

The key insight: digit frequency gives us the upper bound for splits, but we need to try all valid split counts starting from 2.

Lessons Learned

Sometimes the brute force approach needs a bit of finesse. Don't just check one split pattern; check them all within reasonable bounds.

Full code available on my GitHub ⭐

Advent of Code 2025 - Day 1: The Combination Lock

Minindu Rupasinghe — Sat, 06 Dec 2025 17:57:10 +0000

Welcome to my Advent of Code 2025 series! Today we're solving Day 1's puzzle, which involves a combination lock with 100 positions (0-99).

The Problem

We have a dial that starts at position 50, and we need to follow a series of instructions to rotate it left (L) or right (R) by certain amounts. The goal is to count how many times the dial lands on position 0.

Understanding the Modulo Operation

Before diving into the solution, let's understand the key concept: modulo arithmetic.

When we rotate a dial, we need it to "wrap around". If we're at position 99 and move right by 1, we should end up at position 0, not 100. Similarly, if we're at position 0 and move left by 1, we should end up at position 99.

This is where modulo operations come in handy, but there's an important distinction in Rust between % and rem_euclid().

The Difference Between % and rem_euclid()

In Rust, % is the remainder operator, while rem_euclid() is the Euclidean remainder. They behave differently with negative numbers:

Using the % operator:

println!("{}", 5 % 3);      // 2
println!("{}", -5 % 3);     // -2 (negative!)
println!("{}", -1 % 100);   // -1 (negative!)

Using rem_euclid():

println!("{}", 5_i32.rem_euclid(3));      // 2
println!("{}", (-5_i32).rem_euclid(3));   // 1 (positive!)
println!("{}", (-1_i32).rem_euclid(100)); // 99 (positive!)

For our dial problem, this difference is crucial:

If we're at position 0 and move left by 1, we want position 99
With %: (0 - 1) % 100 = -1 ❌ (invalid position!)
With rem_euclid(): (0 - 1).rem_euclid(100) = 99 ✅ (correct!)

The key insight: The % operator can return negative results, which don't make sense for positions on a dial. The rem_euclid() method always returns a non-negative result in the range [0, modulus), which is exactly what we need for circular wrapping.

Part 1: Jump Directly

In the first part, we can jump directly to the final position after each instruction:

fn compute_password1(instructions: Vec<(char, i32)>) -> i32 {
    let mut dial: i32 = 50;
    let mut count: i32 = 0;

    for (dir, dist) in instructions.iter() {
        if *dir == 'L' {
            dial = (dial - dist).rem_euclid(100);
        } else {
            dial = (dial + dist).rem_euclid(100);
        }
        if dial == 0 {
            count += 1;
        }
    }
    count
}

Here, we subtract for left moves and add for right moves, then use rem_euclid(100) to keep the result within 0-99.

Part 2: Step by Step

Part 2 requires us to check every single position we pass through, not just the final position:

fn compute_password2(instructions: Vec<(char, i32)>) -> i32 {
    let mut dial: i32 = 50;
    let mut count: i32 = 0;

    for (dir, dist) in instructions.iter() {
        if *dir == 'L' {
            for _ in 0..*dist {
                dial = (dial - 1).rem_euclid(100);
                if dial == 0 {
                    count += 1;
                }
            }
        } else {
            for _ in 0..*dist {
                dial = (dial + 1).rem_euclid(100);
                if dial == 0 {
                    count += 1;
                }
            }
        }
    }
    count
}

Instead of jumping directly, we move one position at a time and check if we hit 0 after each step.

Parsing the Input

The input file contains instructions like L25, R30, etc. We parse these into tuples of direction and distance:

fn parsing(filename: &str) -> Vec<(char, i32)> {
    let content = fs::read_to_string(filename)
        .expect("Failed to read file");

    content
        .split('\n')
        .map(|s| s.trim().to_string())
        .map(|s| {
            let (first, rest) = s.split_at(1);
            let direction = first.chars().next().unwrap();
            let value: i32 = rest.parse()
                .expect("Expected a number");
            (direction, value)
        })
        .collect()
}

Key Takeaways

Modulo arithmetic is essential for circular/wrapping problems
Use rem_euclid() in Rust, not %, when you need non-negative results for circular wrapping
The % operator can return negative numbers, which break circular logic
Part 1 vs Part 2 shows the difference between checking final states vs intermediate states
Always consider whether you need to track every step or just the destination

Happy coding, and see you tomorrow for Day 2! 🎄

You can find the complete code on my GitHub repository

Building a URL Shortener with Go and Redis

Minindu Rupasinghe — Sat, 08 Nov 2025 13:09:01 +0000

Building a URL Shortener with Go and Redis

Ever wondered how services like bit.ly or TinyURL work? I recently built my own URL shortener as part of the Coding Challenges series, and I'm excited to share what I learned!

🎯 The Challenge

Build a service that:

Takes long URLs and generates short, memorable codes
Redirects users from short URLs to original destinations
Handles millions of URLs efficiently
Deals with hash collisions gracefully

My solution: A Go-based service with Redis for blazing-fast lookups, all containerized with Docker.

📦 Full source code on GitHub

🏗️ Architecture Overview

The system has three main components:

User Request → Go API Server → Redis Database

Why Go?

Fast compilation and execution
Built-in concurrency
Excellent standard library for HTTP

Why Redis?

In-memory storage = microsecond lookups
Simple key-value model perfect for this use case
Persistence options for data durability

🔑 The Core: Hash Generation

The heart of any URL shortener is converting long URLs into short codes. Here's my approach:

func ShortHash(url string) string {
    hash := xxhash.Sum64String(url)
    return EncodeBase62(hash)
}

func EncodeBase62(num uint64) string {
    const base62Chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"

    if num == 0 {
        return "0"
    }

    encoded := ""
    base := uint64(len(base62Chars))

    for num > 0 {
        remainder := num % base
        encoded = string(base62Chars[remainder]) + encoded
        num = num / base
    }

    return encoded
}

Why xxHash?

Extremely fast (GB/s throughput)
Good distribution (fewer collisions)
Non-cryptographic (we don't need security here)

Why Base62?

Uses 0-9, A-Z, a-z (URL-safe)
Shorter than Base16 or Base10
More readable than Base64

Result: https://example.com/page → 2Hs4pQx7 (8 characters)

💥 Handling Collisions

Hash collisions are inevitable. Two different URLs might generate the same short code. Here's how I handle it:

func (a *API) ShortenHandler(w http.ResponseWriter, r *http.Request) {
    normalized := Normalize(payload.URL)
    hash := ShortHash(normalized)

    finalHash := hash
    maxRetries := 10

    for attempts := 0; attempts < maxRetries; attempts++ {
        existing, err := a.Redis.Get(ctx, finalHash).Result()

        // Key doesn't exist - we can use it!
        if err == redis.Nil {
            break
        }

        // Key exists with same URL - return existing
        if existing == normalized {
            return existingShortURL(finalHash, normalized)
        }

        // Collision! Add random suffix
        finalHash = hash + generateRandomSuffix(attempts + 1)
    }

    // Store in Redis
    a.Redis.Set(ctx, finalHash, normalized, 0)
}

Strategy:

Check if hash exists
If it's the same URL, return existing short code
If different URL (collision), append random suffix
Retry up to 10 times
Fail gracefully if all retries exhausted

🔄 URL Normalization

To prevent the same URL from getting multiple short codes, I normalize URLs:

func Normalize(raw string) string {
    u, err := url.Parse(raw)
    if err != nil {
        return raw
    }
    u.Host = strings.ToLower(u.Host)
    return u.String()
}

This ensures:

EXAMPLE.COM → example.com
Example.com → example.com

All variations of the same domain get the same short code!

🐳 Docker Setup

The entire stack runs in Docker with a single command:

# docker-compose.yml
version: '3.8'

services:
  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]

  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      redis:
        condition: service_healthy
    environment:
      - REDIS_HOST=redis
      - SHORT_URL_BASE=http://localhost:8080

Key features:

Health checks ensure Redis is ready before app starts
Persistent volumes keep data safe
Environment variables for easy configuration

📊 Performance Considerations

Current performance:

Hash generation: ~0.1ms
Redis lookup: <1ms
Total response time: ~2ms

Scalability improvements I'd add:

Rate limiting to prevent abuse
Analytics tracking (click counts, referrers)
Custom short codes for vanity URLs
Expiration times for temporary links
Caching layer for hot URLs

🧪 Testing It Out

# Start the service
docker-compose up --build

# Shorten a URL
curl -X POST http://localhost:8080/api/v1/shorten \
  -H "Content-Type: application/json" \
  -d '{"url":"https://github.com/Kryko7/URLShortner"}'

# Response
{
  "key": "xY9pQ2",
  "long_url": "https://github.com/Kryko7/URLShortner",
  "short_url": "http://localhost:8080/xY9pQ2"
}

# Use it
curl -L http://localhost:8080/xY9pQ2
# Redirects to GitHub!

🎓 What I Learned

xxHash is incredibly fast - Perfect for non-cryptographic hashing
Redis is simple but powerful - Key-value stores are underrated
Collision handling matters - Even with good hash functions
Docker makes deployment trivial - One command to run everything
Context timeouts prevent hangs - Always set timeouts for external calls

🚀 Try It Yourself

The full project is open source and ready to run:

GitHub: https://github.com/Kryko7/URLShortner

Challenge: Coding Challenges - URL Shortener

Clone it, run docker-compose up, and you'll have a working URL shortener in 30 seconds!

🔮 Future Improvements

Some ideas I'm considering:

Analytics dashboard - Track clicks, geographic data
Custom aliases - Let users choose their short codes
QR code generation - Generate QR codes for short URLs
API authentication - Protect the service from abuse
Link expiration - Auto-delete old URLs
Batch API - Shorten multiple URLs at once

💬 What Would You Add?

Have ideas for improvements? Found a bug? Want to discuss the architecture?

Drop a comment below or open an issue on GitHub! I'd love to hear your thoughts.

Happy coding! 🎉

If you found this helpful, give the GitHub repo a ⭐ and follow me for more coding challenges!