About Arrays

Arrays and slices hold values, but programs interact with them through indexes (positions)

Example

index: 0 1 2 3
value: 4 7 2 9

Programs don't understand values first, they understand positions.

So basically every algorithm is

• move across indexes (left → right or other way round)

• look at the value at that position

• compare

• update something

• continue… depending on what needs to be done

That is literally the pattern I noticed in almost every exercise I did.

Array Structure

Example

arr := [5]int{10, 20, 30, 40, 50}

What I understand now:

• arrays have fixed size

• they cannot grow

• cannot shrink

• the size is part of the type

So this[5]int means it's type array, and can never be [6]int or anything else

The memory of it looks like

[10][20][30][40][50]

Values can change in position, but you cannot add or remove positions.

Example

arr[2] = 99 (index 2 to be 99)
[10][20][99][40][50]

Array seems pretty straightforward.

Slice

Slices are basically views into an array. I used to think slices were just flexible arrays, but now I understand that they are actually a window/interface into an array.

Example

s := []int{10, 20, 30}
// The [] means slice.

Internally, slice has:

• Pointer: where the slice starts in memory

• Length: how many elements it currently show

• Capacity: how far they can grow

Slice From Array

Example

arr := [5]int{10, 20, 30, 40, 50}
slc := arr[1:4]

Slice becomes

*// start from index 1, count till the 4th item*
[20 30 40]

/* 
	T*he slice did not start counting from array index 1.*
	*Slice index resets.
*/* 
arr[1] -> slc[0] -> 20
arr[2] -> slc[1] -> 30
arr[3] -> slc[2] -> 40

I also noticed a shared memory when I did:

slc[0] = 999

For array, it became:

arr := [10][999][30][40][50]

Seriously confused and surprised because modifying the slice actually modified the array. Meaning that slices share memory with the array, they don’t just copy.

changed the array:

[10][999][30][40][50]

Slices share memory with arrays.

Append Behavior

Append is interestingly funny, I thought it only added items. If the slice has extra capacity, the append writes into the array.

Example I tried:

arr := [6]int{10, 20, 30, 40, 50, 60}
slc := arr[0:4]

slc = append(slc, 70)

// Array becomes
[10 20 30 40 70 60]

70 replaced 50. This, too, surprised me…

This happens because slice still had capacity left inside the array, so Go just used the next slot in the slice, and since slice modifies into its array, it changes the array. But if capacity is full, Go secretly creates a new array, copies values, and then appends. So sometimes slices share memory, sometimes they detach, tricky but interesting.

Length and Capacity

len(slice) = number of elements

cap(slice) = maximum usable space before reallocation.

Example

slc := arr[0:4]

// If array has 6 elements:
len(slc) = 4
cap(slc) = 6

Because slice can extend until end of array.

Problems

1. Check if Slice is Non-Decreasing

arr9 := []int{2, 4, 4, 7, 9}
	/* 
		assume the data is non-decreasing (the curr > or = prev)
		assume true until proven false
	*/
	nonDec := true

	for n := 1; n < len(arr9); n++ {
		if arr9[n] < arr9[n-1] {
			nonDec = false
			break
		}
	}
	fmt.Println(nonDec)

My approach:

• assume nonDec = true

• scan array

• if current < previous -> false

Classic loop was used because I needed access to previous element, and the range loop does not easily give that.

The challenge I had was understanding why the loop started at index 1, because index 0 has no previous element.

1. Strictly Increasing

Check if a Slice Is strictly increasing
	arr10 := []int{2, 4, 4, 7, 9}
	// assume the array is strictly increasing (curr > prev)
	strInc := true

	for o := 1; o < len(arr10); o++ {
		if arr10[o] <= arr10[o-1] {
			strInc = false
			break
		}
	}
	fmt.Println(strInc)

Logic - current must be > previous

Check - arr10[i] <= arr10[i-1]

Challenge was understanding the difference between >=, >, <=, and < for sorted rules.

1. Detect Sorted (Ascending / Descending / Not Sorted)

/* 
	Check if the array is sorted (ascending) – Return true if sorted, otherwise false.
*/
	// arr6 := []int{1, 2, 3, 5, 4, 6}
	arr6 := []int{10, 20, 15, 30}
	sorted := true // assume true until proven otherwise

	// start from index 1 not zero so that i-1 will be within the range
	for i := 1; i < len(arr6); i++ {
		if arr6[i] < arr6[i-1] {
			sorted = false
			break
		}
	}

	fmt.Println(sorted)

	// for-range version
	for ind := range arr6 { // ignore values, not index
		if ind == 0 {
			continue
		}
		if arr6[ind] < arr6[ind-1] {
			sorted = false
			break
		}
	}

	fmt.Println(sorted)

As I mentioned earlier :

current > previous -> ascending
current < previous -> descending
mix -> not sorted

This requires neighbour comparison, so classic loop it is.

1. Find Largest Number

	// Find the largest odd number
	arr12 := []int{12, 7, 19, 3, 19, 5}
	lgst := arr12[0]

	for q := 0; q < len(arr12); q++ {
		if arr12[q] >= lgst && arr12[q] % 2 == 0 { // largest even
			lgst = arr12[q]
		}
	} 
	fmt.Println(lgst)
	
// for-range version
	for val := range arr12 {
		if arr12[val] >= lgst && arr12[val] % 2 == 1 { // largest odd
			lgst = arr12[val]
		}
	}
	fmt.Println(lgst)

Running comparison pattern is classic algorithm pattern, I did both classic loop and range loop. Range worked only because the values were compare.

largest item = arr12[0]
scan rest
if current >= largest
update largest

1. Find Second Largest (Distinct)

// Find the second‑largest element (invariant)
	arr7 := []int{12, 7, 19, 3, 19, 5}

	// assume the indices of max and second max
	maxx := arr7[0]
	secMax := arr7[1]

	for i := 0; i < len(arr7); i++ {
		if arr7[i] > maxx {
			secMax = maxx
			maxx = arr7[i]
		} else if arr7[i] < maxx && arr7[i] > secMax {
			secMax = arr7[i]
		}
	}
	fmt.Println("Second Largest: ", secMax)

	// Deduplicate an array
	arr8 := []int{4, 2, 4, 6, 2, 8, 6}
	arrMap := make(map[int]bool) // for validation
	var newArr8 []int

	for _, m := range arr8 {
		if !arrMap[m] {
			newArr8 = append(newArr8, m)
			arrMap[m] = true
		} 
	}
	fmt.Println("New Array: ", newArr8)

Idea:

largest = arr7[0]
secondLargest = arr7[1]

if current > largest
    second = largest
    largest = current
    
if current < largest AND current > second
    second = current

My challenge here was “what if there are duplicates?”. “What happens when first many indexes are same value?”

Example:

[9,7,9,8] [4, 4, 4, 4, 4, 6, 1, 8, 0]

The solution is to never assume unique first two values, also learned about initializing the second value properly (don’t understand it yet)

1. Remove negatives, new slice and in-place

	// Remove all negatives (new slice)
	arr5 := []int{-3, 5, -1, 0, 8, -2, 7}
	var nonNegArr5 []int

	for _, j := range arr5 {
		if j >= 0 {
			nonNegArr5 = append(nonNegArr5, j)
		}
	}
	fmt.Println("Non-negative = ", nonNegArr5)

	// Remove all negatives in place with while-style loop
	arrr := []int{-3, 5, -1, 0, 8, -2, 7} 
	j := 0

	for j < len(arrr) {
		if arrr[j] < 0 { 
			j++
			continue
		}
		fmt.Println(arrr[j])
		j++
	}

The goal was to create slice with only non-negative numbers.

• When arr[j] < 0, the continue skips printing, and goes back to check j < len(arr).

• Because j++ is before continue, the loop moves to the next instead of looping infinitely on the same index.

• This made me understand why the while-style loop needs manual control of the index.

The appropriate loop is Range-Loop, because it was just to scan values

*if value >= 0, then
append*

Here, the issue I faced with the “while-loop version” made me understand “j++” must come before the “continue”, why that is, and how “continue” works internally.

*continue doesn’t mean “skip this part and then move forward before updating the index,” as I used to think; it immediately ends the current iteration and jumps back to the loop condition, and then moves to the next iteration. It stops executing the rest of the code inside the loop after the continue, and moves to the next iteration. If you don’t manually update the index before it, the loop gets stuck*

continue -> stop executing remaining code in loop -> jump to the loop's next iteration

for i := 0; i < 5; i++ {
	fmt.Println("A")
	continue

	fmt.Println("B")
}

// prints "A" 5times, "B" never print
// fmt.Println("B") is skipped.

This also made me understand that:

• Classic for loop gives full index control → perfect for in-place, neighbor index slice modifications.

• Range loop automatically handles iteration → perfect for when the problem only care about values, not modifying the indexes.

• Misplacing continue or forgetting manual index in a while-style loop → leads to skipped items, infinite loops, or being stuck.

I tried removing the negatives in place using the same code example

	// Remove all negatives in place with while-style loop
	arrr := []int{-3, 5, -1, 0, 8, -2, 7} 
	j := 0

	for j < len(arrr) {
		if arrr[j] < 0 { 
			j++
			continue
		}
		fmt.Println(arrr[j])
		j++
	}

What I did was:

• remove the element if it’s negative

• let the rest shift left automatically

• use continue to skip the remaining

I came to see that

• repeated shifting is inefficient

• every removal moves all elements after it, which will be slow for big slices

• it is hard to track indexes, and it is easy to skip elements or get into infinite loop

Better approach is to

• use overwrite and truncate, which I am currently trying to understand, my brain feels tired right now!!

Loop Types in Go

Classic For Loop (Index Control)

This gives full control over the index and value, perfect for neighbor comparisons, in-place modifications, skipping items, backward iteration, etc…

for i := 0; i < len(arr); i++ {
}

Classic Index Loop:

• used when index control is needed like skip, jump, backwards

• when need to compare previous/next element

• need to modify element in-place, eg reverse positioning, insert

Example

arr[i] vs arr[i-1]

Range loop cannot easily do this.

Range Loop (Consumer Loop)

For-Range is mostly a consumer loop in order; it takes in and processes existing data or works on existing data. Perfect for when just values are needed, no shifting or neighbor comparisons.

for index, value := range arr {
}
/* 
	it iterate from left to right
	treates items as READ-ONLY
	visit each element exactly once
*/

For-Range cannot access neighbor items, like in ordering or sorting existing data. Like checking about the previous or next element, it cannot change the data position by itself. It only cares about the current and moving to the next and the next. It is PERFECT for data, where each element can be processed independently

• used when index is not needed

• when just reading the values

• used when clarity is needed

• cannot manipulate data

• it consumes items in order

While-Style Loop in Go

While loop does not do automatic increment, code gets into infinite loops if you forget i++.

for input != "quit" {
}

• use when reading user input

• when scanning streams

• good for state changes

• when unknown iteration counts

For arrays & slices in Go, classic and range loops are preferable, because classic for gives the same flexibility, and it’s safer.

The Things I learned

• Slices share memory with arrays.

• Append can modify original array.

• Most array problems are pattern recognition.

• What each loop type are best for.

• Not knowing what kind of problem I was solving.

• I can think of possible ways and ideas to solve problems, but putting them together in a logical sequence is the challenge.

• Mental pressure to solve, trying to code before having clarity

• Learning tools without concepts

What I learnt

Control flow is basically about decision + repetition

• loop (for / while-style) = tracking, repetition

• conditions (if / else, true or false)

• continue/break = when to skip or stop

• nesting (loops inside loops)

• state = memory

• decision = transition

Also learned how to:

• pause/calm before coding

• classify the problem

• choose tools intentionally (flexible)

• separate problem type from syntax, they are not the same.

3 Core Control Flow Moves

Sequence: Running instructions from top to bottom.

Decision (Branching): “If this is true, do A. Otherwise, do B.”

I realize that if does not belong to loops, it can exist anywhere (outside or inside), loops just repeat decisions, thats all.

Repetition (Loops): Keep doing this while a condition is true.

Types of Loops

• Classic for Loop: when I know the count, how many times the program should run.

Examples are print 1 to 10, iterate over array indices, fixed grid sizes

for i := 1; i <= 10; i++ {
     fmt.Println(i)
}

• i = starts

• condition is checked

• body runs

• i changes

• repeat

If the condition is false at any point, loop stops.

i == max is WRONG, == means *only when exactly equal*
i <= max is CORRECT, <= means *until it reaches*

• While-Style Loop: when I don’t know the count, or how many times the program will run or user will input

Examples are:

user input, password attempts, read until 0, read until "done"

for n != 0 {
     fmt.Scan(&n)
}

With while-loop, there is no counter, no increment section, only a condition. It’s more flexible.

Control Flow Patterns/Concepts

1. Counter Loop: How many times, used when the number of iterations matters more than the values.

Thought process

• Something to happen in a fixed number of times, it’s about the count

• A counter starts somewhere, usually 0 or 1

• It changes predictably

• The loop ends when the count is reached

Example task

• Print the first 10 numbers

• Print 8 odd numbers

• Repeat an action 5 times

• Print the first 8 odd numbers.

Reasoning

• I need 8 outputs → counter

• Odd numbers → start at 1

• Next odd = +2

• Stop after 8 prints

Code for (Print the first 8 odd numbers.)

count := 0

for i := 1; count < 8; i += 2 {
        fmt.Println(i)
        count++
}

Note: loop variable (i) and the reason for stopping (counter) do NOT have to be the same thing, because an external counter is required here to get cleaner output.

1. Sentinel Loop: Run until something happens. Important concept in While-loop.

Thought process

• Don’t know how many times, stop when there’s a signal.

• The signal is the sentinel, can 0, negative number, "stop", “done”, etc.

• Read input

• Check sentinel condition

• Continue until sentinel appears

• What matters is not the loop, it’s the sentinel condition.

Example task

Read numbers until the user enters 0.

Reasoning

• Does not matter how many numbers or times the user inputs

• If it is 0, stop

• Everything else continues

Code

var n int

fmt.Scan(&n)

for n != 0 { // if n is not 0, continue to print n, stop when n is 0
        fmt.Println(n)
        fmt.Scan(&n)
}

Note: The loop condition is the stopping logic, not an if (which can also be used in this case). If the condition is false, the loop doesn’t run. I don’t need break if the condition already encodes the stop. This was a shift for me, and I got it.

1. Accumulator: compressing many values into one result.

Thought process

• Every input matters, but only keep a summary.

• Sum, count, max, min, and average all are same family.

• Initialize accumulator

• Update it every iteration

• Use comparison or addition

Example task A: Sum

Sum numbers until 0.

sum := 0
var n int

fmt.Scan(&n)

for n != 0 {
        sum += n
        fmt.Scan(&n)
}

Example task B: Max (this one confused me, rightly)

Read numbers until 0 and find the max.

Reasoning

• No input is deleted or skipped

• Every number is read/compared

• I keep one running value

• Sentinel loop, running comparison, store single value

Code

var n int

fmt.Scan(&n)
max := n

for n != 0 {
        if n > max {
            max = n
        }
    fmt.Scan(&n)
}

Note: Finding max/min is not filtering, because I am not removing any input, I’m comparing every input against a stored state. It is a running comparison, a form of accumulation.

1. Filter: Some inputs don’t participate, different from accumulation.

Thought process

• Ignore some values.

• If & continue needed here.

• Read input

• Test condition

• Skip or select

Example tasks

• Ignore negatives

• Skip multiples of 3

• Count only evens

• Ignore values in a range

• Count even numbers until 0.

Code for (Count even numbers until 0)

count := 0
var n int

fmt.Scan(&n)

for n != 0 {
        if n % 2 != 0 {
                fmt.Scan(&n)
                continue
        }
        count++ (external counter)
        fmt.Scan(&n)
}

Note: Filtering means some inputs are discarded, which is different from max/min, where all inputs participate (accumulation).

1. Step Loop: Jumping with intention

Thought process

• The sequence itself has a pattern.

• Loop + “if” can be used but cleaner is “controlled stepping”

• No filtering needed

• Skipping is needed

Example task

• Even numbers

• Countdown by 2s

// Print multiples of 5 from 5 to 50.
for i := 5; i <= 50; i += 5 { // skip/jump: “i += 5”
        fmt.Println(i)
}

Note: If the pattern is numeric, encode it in the step, not with if.

1. Shifting/Top-N: Keep the best few (this was stateful)

Thought process

• Keeping the ranked state is important

• Best 3 values seen so far.

• Compare

• Shift values down (reassignment)

• Insert at the top (preserve the order)

Example task

Concept (not code)

// Track top 3 numbers entered.
new > first → shift (first → second → third)
new > second → shift
new > third → replace

Note: This is controlled mutation. It builds on max/min, but extended with shifts & slots

1. Nested Loops: Multiple dimensions (it clicked when I stopped thinking of them as “nested” but as outer loop & inner loop)

Thought process

• The first loop is the row, another is the column.

• Row loop defines context, time periods, column defines the relationship, it repeats within it

• Outer loop = big picture

• Inner loop = repeated detail

Example task

// Print a 4×4 grid. 
for row := 1; row <= 4; row++ {
        for col := 1; col <= 4; col++ {
                fmt.Print("*")
        }
    fmt.Println()
}

// Example 2: multiplication table.
for row := 1; row <= 10; row++ {
    for col := 1; col <= 10; col++ {
        fmt.Printf("%d x %d = %d\\n", row, col, row*col)
    }
}

Note: Nested loops are not difficult, they’re just layered repetition. The inner loop completes before outer loop continues.

1. Map-Based Uniqueness: Something seen before, memory needed not repetition

Thought process

• Memory needed.

• Map for tracking

• Loop for reading

• Conditional check

• Past inputs matter

• Uniqueness matters

Example task

Count unique numbers entered.

seen := make(map[int]bool)
var n int

fmt.Scan(&n)
        for n != 0 {
                if !seen[n] {
                seen[n] = true
        }
    fmt.Scan(&n)
}

Producer vs Consumer Loops (this was a good realization, I picked up from learning this pattern) The third loop in Go, “for-range”, is for consuming existing data. while-style for is for producing data. Producer loop You are creating a new data from the input:

for input != "done" {
    fmt.Scan(&input)
}

Consumer loop You are using (iterating through) an existing data:

for _, name := range names {
    fmt.Println(name)
}

Note: When loops alone aren’t enough, data structures enter. The loop needs to remember what it has already seen, and the map keeps track.

Now I understand that Control flow is not just about writing loops, it’s about recognizing repetition, decisions, state, and stopping conditions.

Before writing any for or if code, I pause and answer the following questions, to know the tools and concepts required.

1. What kind of problem is this (Repetition? Decision? Accumulation? Selection? Ranking Memory?)

2. Am I repeating something, tracking something, or deciding something?

3. What state must I remember while the program runs?

4. What event or condition stops this process?

Every control-flow problem fits into one or more of these.

Building the Email 2FA (Two-Factor Authentication) feature for my backend.

Stack: Go, GORM, RabbitMQ, Elastic Email.

This is me, understanding how everything connects. This is not a tutorial, just real notes from debugging and clarity.

Starting Point

I wanted users to get an OTP (One-Time Password) via email for 2FA.

Simple idea: user requests → generate code → send email to user’s email address.

In reality, it went more like this:

User clicks "Send OTP" → Client
Backend generates OTP → Code logic
Producer - Publishes message to RabbitMQ → Queue
Consumer picks it up → Message picker
Delivers email via Elastic Email (SMTP)

And somewhere in that chain, something always went wrong.

Error 1: “relation ‘otp_verifications’ does not exist”

This one was simple in hindsight:

GORM tried to insert into a table that didn’t exist yet.

I had created this OtpVerification model below, but didn’t migrate it to my database.

type OtpVerification struct {
    ID        uuid.UUID `gorm:"primarykey"`
    UserID    uuid.UUID
    OtpCode   string
    ExpiresAt time.Time
    Verified  bool
    CreatedAt time.Time
}

The Fix

The fix was just to have it running in the database: db.AutoMigrate(&models.OtpVerification{}).

Lesson: GORM doesn’t magically create tables; migration is my responsibility, geez!!.

Error 2: “Unknown task type from email_otp_queue”

I am using RabbitMQ to send tasks to a background worker.

I wanted to publish a message to a queue and have another process handle the actual email sending.

Producer = the Go service that publishes the task in connection with the RabbitMQ (queue)

Consumer = the background worker that reads and processes the task for delivery.

My mistake: when I published the OTP message, I didn’t add targeted user’s email address and specify the type properly.

Here’s the code that was broken:

utils.PublishMessage(
    os.Getenv("EMAIL_OTP_QUEUE"),
    otp.UserID.String(), // userID instead of email
    generateOtp,
    "",                  // empty description
    "",
    user.Email,
    "",
)

The consumer was expecting a "Type": "otp" message to know which handler to call.

But I sent an empty string. So RabbitMQ successfully added it to the queue, but the consumer didn’t know what to do because of “unknown task type.” This mistake was an oversight; I copied the code block from a different feature and forgot to modify it.

The Fix

After understanding what was happening, I updated it:

utils.PublishMessage(
    os.Getenv("EMAIL_OTP_QUEUE"),
    user.Email,       // email
    generateOtp,
    "otp",            // OTP
    "",
    "",
    "",
)

Now the logs looked like this:

Published task to email_otp_queue for oyi.....@gmail.com
Sent otp email to oyi.....@gmail.com

Finally sent the OTP to my inbox, and yeah, I got it.

Lesson:

• Always review and verify copied code blocks

Error 3: “535 Authentication failed: Access denied”

This one was from Elastic Email (deliverer). I had changed my account email to oyi.....@gmail.com, but my SMTP username was still the old aod.....@gmail.com. Elastic Email SMTP credentials are account-level, not tied to the sender identity only.

Even though I verified the new email, the actual SMTP authentication was still using the old one.

The dashboard said:

“For testing purposes, you can only send to your registered email address.”

I knew about Elastic Email restrictions on free accounts to send only to the verified sender address for testing, which I had done.

The Fix

I created a new SMTP using the new, active (verified) account, deleted the old one, and it worked, I got the OTP email.

Lessons:

• You can verify multiple “from” addresses on Elastic Email

• But your SMTP username remains the one you registered with (main issue)

• If you change your login email, you may need a new API key

How It All Connects (my mental model now)

User → /request-otp → Service layer → PublishMessage()
       → RabbitMQ queue → EmailConsumer → SendMail() → Elastic Email → Inbox

Each layer has its responsibility:

• Service layer - business logic (create OTP, store it in the db)

• Publisher - posts a task to RabbitMQ i.e queue

• Consumer - listens, reads the message, and executes email sending

• Elastic Email (SMTP) - actually delivers the email to the user

RabbitMQ is just the middleman, like a post office between the app and the worker that sends the mail. Both the publisher (producer) and consumer are connected to the RabbitMQ

Key Lessons

1. Every queue message must match what the consumer expects, fields, types, and purpose.

2. SMTP credentials are tied to your sending account, not your email variable.

3. RabbitMQ doesn’t execute, it only transfers.

4. Always test both ends: producer and consumer.

5. Logs are your ally, Oyindamola, read them slowly.

6. The real “fix” is understanding the flow, not just changing code.

Clarity: The architecture makes sense now. It taught me how background queues actually work, how they all connect to achieve the end goal.