DEV Community: Ahmed Raza Idrisi

Using Redis for API Caching in Go (Speed Up Your Backend)

Ahmed Raza Idrisi — Sat, 09 May 2026 13:15:34 +0000

After building APIs in Go, the next big question is:

👉 How do you make them faster?

This is where Redis comes in.

In this post, we’ll:

Connect Go with Redis
Cache API responses
Reduce database load
Improve performance

🧠 What is Redis?

Redis is an in-memory database used for:

Caching
Sessions
Queues
Real-time systems

Think of Redis like:
👉 “Super-fast temporary storage”

Instead of hitting PostgreSQL every time:

First request → DB
Next requests → Redis cache ⚡

⚙️ Install Redis Package

```bash id="gq78f0"
go get github.com/redis/go-redis/v9




---

## 📦 Connect Redis



```go id="lb7m2n"
package main

import (
    "context"
    "github.com/redis/go-redis/v9"
)

var ctx = context.Background()

var rdb = redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})

🗄️ Example API Response

Normally:

```go id="1h9v4t"
func getUsersFromDB() string {
return "Users from PostgreSQL"
}




But hitting DB repeatedly is expensive.

---

## ⚡ Add Redis Caching



```go id="h4m92g"
func getUsers(w http.ResponseWriter, r *http.Request) {

    cachedData, err := rdb.Get(ctx, "users").Result()

    if err == nil {
        w.Write([]byte("Cache Hit 🚀\n" + cachedData))
        return
    }

    data := getUsersFromDB()

    rdb.Set(ctx, "users", data, time.Minute*5)

    w.Write([]byte("DB Hit 🐘\n" + data))
}

🔥 What’s Happening Here?

First Request

Redis has no data
Fetch from DB
Store in Redis

Next Requests

Redis already has data
Return instantly ⚡

📊 Why Caching Matters

Without cache:

Client → API → Database

With cache:

Client → API → Redis ⚡
             ↓
          Database (less often)

🚀 Benefits of Redis

Faster APIs
Reduced DB load
Better scalability
Improved user experience

⚠️ Important Production Notes

Don’t cache forever.

Always:

Set expiration time
Clear cache after updates
Avoid stale data

🧭 Real-World Usage

Redis is used in:

Authentication systems
Rate limiting
API caching
Queues
Real-time apps

Companies like:

Netflix
Instagram
Twitter

use Redis heavily.

💬 Final Thought

Caching is one of the easiest ways to improve backend performance.

You don’t always need:

Bigger servers
More CPUs

Sometimes…
👉 You just need smarter architecture.

🚀 Coming Next

👉 Rate Limiting in Go API
👉 Background Jobs with Redis
👉 Redis Pub/Sub in Go

Structuring a Go API Like Laravel (Controller, Service, Repository)

Ahmed Raza Idrisi — Mon, 04 May 2026 11:39:24 +0000

If you're coming from Laravel, one thing feels missing in Go:

👉 Structure

By default, Go gives you freedom—but no clear architecture.

So in this post, we’ll structure a Go API like Laravel:

Controller → Handle request
Service → Business logic
Repository → Database

🧠 Why Structure Matters

Without structure:

Code becomes messy quickly
Hard to scale
Difficult to debug

With structure:

Clean separation of concerns
Easier testing
Production-ready codebase

📁 Folder Structure

project/
 ├── main.go
 ├── controller/
 ├── service/
 ├── repository/
 ├── model/

🧱 Model (model/user.go)

```go id="6pn1u5"
package model

type User struct {
ID int json:"id"
Name string json:"name"
}




---

## 🗄️ Repository Layer

Handles database queries



```go id="aq1u8u"
package repository

import (
    "database/sql"
    "yourapp/model"
)

type UserRepository struct {
    DB *sql.DB
}

func (r *UserRepository) GetAll() ([]model.User, error) {
    rows, err := r.DB.Query("SELECT id, name FROM users")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []model.User

    for rows.Next() {
        var user model.User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    return users, nil
}

⚙️ Service Layer

Handles business logic

```go id="qf1kmz"
package service

import (
"yourapp/model"
"yourapp/repository"
)

type UserService struct {
Repo *repository.UserRepository
}

func (s *UserService) GetUsers() ([]model.User, error) {
return s.Repo.GetAll()
}




---

## 🌐 Controller Layer

Handles HTTP requests



```go id="n8t1rn"
package controller

import (
    "encoding/json"
    "net/http"
    "yourapp/service"
)

type UserController struct {
    Service *service.UserService
}

func (c *UserController) GetUsers(w http.ResponseWriter, r *http.Request) {
    users, err := c.Service.GetUsers()
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(users)
}

🚀 main.go (Wire Everything)

```go id="b4r8f2"
package main

import (
"database/sql"
"log"
"net/http"

_ "github.com/lib/pq"

"yourapp/controller"
"yourapp/repository"
"yourapp/service"

)

func main() {
db, _ := sql.Open("postgres", "your_connection_string")

repo := &repository.UserRepository{DB: db}
service := &service.UserService{Repo: repo}
controller := &controller.UserController{Service: service}

http.HandleFunc("/users", controller.GetUsers)

log.Println("Server running on :8080")
http.ListenAndServe(":8080", nil)

}




---

## 🔥 What You Achieved

* Clean architecture like Laravel
* Separation of concerns
* Scalable Go backend structure

---

## 🧭 When to Use This

Use this structure when:

* Building real APIs
* Working in teams
* Scaling projects

---

## 💬 Final Thought

Go doesn’t force structure…

👉 But professionals create one.

If you combine Go performance with Laravel-style architecture, you get the best of both worlds.

---

## 🚀 Coming Next

👉 Add middleware (logging, auth)
👉 Add validation layer
👉 Dockerize Go + PostgreSQL

---

#golang #backend #architecture #programming #webdev

Structuring a Go API Like Laravel (Controller, Service, Repository)

Ahmed Raza Idrisi — Thu, 30 Apr 2026 19:21:12 +0000

If you're coming from Laravel, one thing feels missing in Go:

👉 Structure

By default, Go gives you freedom—but no clear architecture.

So in this post, we’ll structure a Go API like Laravel:

Controller → Handle request
Service → Business logic
Repository → Database

🧠 Why Structure Matters

Without structure:

Code becomes messy quickly
Hard to scale
Difficult to debug

With structure:

Clean separation of concerns
Easier testing
Production-ready codebase

📁 Folder Structure

project/
 ├── main.go
 ├── controller/
 ├── service/
 ├── repository/
 ├── model/

🧱 Model (model/user.go)

```go id="6pn1u5"
package model

type User struct {
ID int json:"id"
Name string json:"name"
}




---

## 🗄️ Repository Layer

Handles database queries



```go id="aq1u8u"
package repository

import (
    "database/sql"
    "yourapp/model"
)

type UserRepository struct {
    DB *sql.DB
}

func (r *UserRepository) GetAll() ([]model.User, error) {
    rows, err := r.DB.Query("SELECT id, name FROM users")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []model.User

    for rows.Next() {
        var user model.User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    return users, nil
}

⚙️ Service Layer

Handles business logic

```go id="qf1kmz"
package service

import (
"yourapp/model"
"yourapp/repository"
)

type UserService struct {
Repo *repository.UserRepository
}

func (s *UserService) GetUsers() ([]model.User, error) {
return s.Repo.GetAll()
}




---

## 🌐 Controller Layer

Handles HTTP requests



```go id="n8t1rn"
package controller

import (
    "encoding/json"
    "net/http"
    "yourapp/service"
)

type UserController struct {
    Service *service.UserService
}

func (c *UserController) GetUsers(w http.ResponseWriter, r *http.Request) {
    users, err := c.Service.GetUsers()
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(users)
}

🚀 main.go (Wire Everything)

```go id="b4r8f2"
package main

import (
"database/sql"
"log"
"net/http"

_ "github.com/lib/pq"

"yourapp/controller"
"yourapp/repository"
"yourapp/service"

)

func main() {
db, _ := sql.Open("postgres", "your_connection_string")

repo := &repository.UserRepository{DB: db}
service := &service.UserService{Repo: repo}
controller := &controller.UserController{Service: service}

http.HandleFunc("/users", controller.GetUsers)

log.Println("Server running on :8080")
http.ListenAndServe(":8080", nil)

}




---

## 🔥 What You Achieved

* Clean architecture like Laravel
* Separation of concerns
* Scalable Go backend structure

---

## 🧭 When to Use This

Use this structure when:

* Building real APIs
* Working in teams
* Scaling projects

---

## 💬 Final Thought

Go doesn’t force structure…

👉 But professionals create one.

If you combine Go performance with Laravel-style architecture, you get the best of both worlds.

---

## 🚀 Coming Next

👉 Add middleware (logging, auth)
👉 Add validation layer
👉 Dockerize Go + PostgreSQL

---

#golang #backend #architecture #programming #webdev

🏗️ System Architecture Simplified: From Monolith to Microservices (With Real Insights)

Ahmed Raza Idrisi — Mon, 27 Apr 2026 11:18:50 +0000

When you start building applications, everything feels simple — one codebase, one database, one deployment. But as your app grows, things start breaking in subtle ways: slow performance, deployment risks, tight coupling.

That’s where System Architecture becomes critical.

Let’s break it down in a practical, developer-first way.

🔹 What is System Architecture?

System Architecture defines:

How components interact
How data flows
How scalable and maintainable your system is

Think of it as the blueprint of your application.

🔹 Monolithic Architecture (Where Most of Us Start)

In a monolith:

Everything is in one codebase
One database
Single deployment unit

✅ Pros:

Simple to build and deploy
Easy debugging (initially)
Great for MVPs

❌ Cons:

Hard to scale specific parts
Deployment becomes risky
Tight coupling across modules

Example (Laravel App):

Auth + Payments + Orders + Notifications → all inside one project

🔹 When Monolith Starts Failing

You’ll notice:

Small changes break unrelated features
Deployments take longer
Scaling requires scaling everything
Teams step on each other’s code

This is the point where you rethink architecture.

🔹 Microservices Architecture

Instead of one big app:
👉 You split into independent services

Example:

Auth Service
Payment Service
Order Service
Notification Service

Each service:

Has its own codebase
Can have its own database
Is deployed independently

🔹 Microservices Pros & Cons

✅ Pros:

Independent scaling
Faster deployments
Better fault isolation
Tech flexibility (Go, Node, PHP, etc.)

❌ Cons:

Network complexity
Debugging becomes harder
Requires DevOps maturity
Distributed data challenges

🔹 Real-World Architecture Pattern

A common modern setup:

[ Client (Vue/React) ]
          ↓
     API Gateway
          ↓
 ┌────────┼────────┐
 ↓        ↓        ↓
Auth   Orders   Payments
Svc     Svc       Svc
 ↓        ↓        ↓
 DB       DB       DB

🔹 Key Concepts You Must Know

1. API Gateway

Single entry point
Handles auth, routing, rate limiting

2. Service Communication

REST (simple)
gRPC (fast, efficient)
Message Queues (async processing)

3. Database Strategy

Shared DB ❌ (avoid)
Database per service ✅

4. Caching Layer

Redis for performance boost

5. Queue System

Background jobs (emails, reports)
Tools: Redis queues, Kafka, RabbitMQ

🔹 Monolith vs Microservices (Quick Comparison)

Feature	Monolith	Microservices
Deployment	Single	Independent
Scaling	Full app	Service-level
Complexity	Low	High
Flexibility	Low	High

🔹 What Should YOU Choose?

👉 If you're building:

MVP / Startup → Monolith
Growing SaaS → Modular Monolith
Large-scale system → Microservices

💡 Pro tip:
Don’t jump to microservices too early. Scale your architecture only when needed.

🔹 Final Thoughts

System architecture is not about trends — it’s about trade-offs.

Start simple.
Measure pain points.
Evolve your architecture.

That’s how real systems are built.

🚀 Building a CRUD API in Go with PostgreSQL (Step-by-Step)

Ahmed Raza Idrisi — Mon, 27 Apr 2026 11:09:38 +0000

In the previous post, we built a simple CRUD API in Go using in-memory storage.

Now let’s make it real-world ready by connecting it to a database:

👉 PostgreSQL

⚙️ Step 1: Install PostgreSQL Driver

We’ll use the official driver:

go get github.com/lib/pq

🧱 Step 2: Setup Database Connection

package main

import (
    "database/sql"
    "log"

    _ "github.com/lib/pq"
)

var db *sql.DB

func initDB() {
    connStr := "user=postgres password=postgres dbname=testdb sslmode=disable"

    var err error
    db, err = sql.Open("postgres", connStr)
    if err != nil {
        log.Fatal(err)
    }

    err = db.Ping()
    if err != nil {
        log.Fatal("DB not reachable:", err)
    }

    log.Println("Connected to PostgreSQL ✅")
}

🗄️ Step 3: Create Table

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

🧩 Step 4: Model

type User struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

➕ Create User (INSERT)

func createUser(w http.ResponseWriter, r *http.Request) {
    var user User
    json.NewDecoder(r.Body).Decode(&user)

    err := db.QueryRow(
        "INSERT INTO users(name) VALUES($1) RETURNING id",
        user.Name,
    ).Scan(&user.ID)

    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(user)
}

📥 Get Users (SELECT)

func getUsers(w http.ResponseWriter, r *http.Request) {
    rows, err := db.Query("SELECT id, name FROM users")
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    defer rows.Close()

    var users []User

    for rows.Next() {
        var user User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    json.NewEncoder(w).Encode(users)
}

✏️ Update User

func updateUser(w http.ResponseWriter, r *http.Request) {
    idParam := r.URL.Query().Get("id")

    var user User
    json.NewDecoder(r.Body).Decode(&user)

    _, err := db.Exec(
        "UPDATE users SET name=$1 WHERE id=$2",
        user.Name, idParam,
    )

    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode("Updated")
}

❌ Delete User

func deleteUser(w http.ResponseWriter, r *http.Request) {
    idParam := r.URL.Query().Get("id")

    _, err := db.Exec("DELETE FROM users WHERE id=$1", idParam)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode("Deleted")
}

🌐 Step 5: Main Function

func main() {
    initDB()

    http.HandleFunc("/users", getUsers)
    http.HandleFunc("/create", createUser)
    http.HandleFunc("/update", updateUser)
    http.HandleFunc("/delete", deleteUser)

    log.Println("Server running on :8080")
    http.ListenAndServe(":8080", nil)
}

🧪 Test API

Same as before, but now data is stored in PostgreSQL 🎉

⚠️ Improvements You Should Do Next

This is still beginner-level. To make it production-ready:

Use environment variables for DB config
Add validation
Use a router (Chi / Gorilla Mux)
Structure code (controllers, services, repo)
Add connection pooling tuning

🔥 What You Learned

Connecting Go to PostgreSQL
Executing SQL queries (INSERT, SELECT, UPDATE, DELETE)
Handling real database-backed APIs

🚀 Coming Next

👉 Proper API structure in Go (like Laravel mindset)
👉 Using Docker with Go + PostgreSQL
👉 Adding authentication (JWT)

💬 Final Thought

Now you're no longer just learning Go…

👉 You're building backend systems.

🔥 Arrays vs Slices in Go (Explained in the Simplest Way)

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:10:21 +0000

If you just started learning Go, one thing will confuse you quickly:

👉 Arrays vs Slices

They look similar… but behave very differently.

Let’s break it down in the simplest way possible 👇

📦 What is an Array?

An array is a fixed-size collection.

numbers := [3]int{1, 2, 3}

Key points:

Size is fixed
Cannot grow or shrink
Rarely used in real-world Go apps

🔄 What is a Slice?

A slice is a dynamic version of an array.

numbers := []int{1, 2, 3}

Key points:

Size is dynamic
Can grow using append
Used almost everywhere in Go

⚡ Adding Data (Only Works with Slice)

numbers := []int{1, 2, 3}

numbers = append(numbers, 4)

Now:

[1, 2, 3, 4]

🧠 Under the Hood (Important Concept)

A slice is:

Pointer to an array
Length
Capacity

Think of it like:
👉 “A flexible view on top of an array”

🔍 Slice Example with Capacity

numbers := make([]int, 2, 5)

fmt.Println(len(numbers)) // 2
fmt.Println(cap(numbers)) // 5

❗ Common Mistake

arr := [3]int{1,2,3}
arr = append(arr, 4) // ❌ ERROR

Why?
👉 Because arrays are fixed size

🔥 Real-World Use Case

When building APIs:

users := []string{}

users = append(users, "Ahmed")
users = append(users, "John")

Dynamic data = slices ✅

🧭 When to Use What?

Feature	Array	Slice
Size	Fixed	Dynamic
Usage	Rare	Common
Flexibility	❌	✅

👉 In 95% of cases → use slice

💬 Final Thought

If you understand slices, you understand how Go manages data internally.

This is a foundational concept—don’t skip it.

🚀 Coming Next

Next post:
👉 Structs in Go (this is where real backend modeling starts)

golang #backend #programming #webdev #devto

🚀 Getting Started with Go (Golang) for Backend Developers

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:07:57 +0000

If you're coming from PHP, Node.js, or Laravel, learning Go can feel different—but in a good way.

Go is designed for performance, simplicity, and concurrency. Many modern systems use it for building fast APIs and scalable services.

Let’s understand it in a simple way 👇

🧠 What is Go?

Go (or Golang) is a compiled programming language created at Google.

Think of it like:

⚡ Faster than PHP/Node (compiled)
🧼 Cleaner syntax than Java
🔁 Built for concurrency (handling multiple tasks efficiently)

⚙️ Your First Go Program

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

What’s happening?

package main → entry point
import "fmt" → used for printing
func main() → main function where execution starts

🔤 Variables in Go

name := "Ahmed"
age := 25

No need to write types explicitly (Go infers them).

🔁 Loops (Only ONE loop in Go)

for i := 0; i < 5; i++ {
    fmt.Println(i)
}

Simple and clean.

⚡ Functions

func add(a int, b int) int {
    return a + b
}

🧵 Concurrency (This is where Go shines)

Go uses goroutines (lightweight threads):

go func() {
    fmt.Println("Running in background")
}()

Why this matters:

Handle multiple API requests easily
Build high-performance systems
Perfect for microservices

🌐 Simple API in Go

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello from Go API")
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Run it and open:
👉 http://localhost:8080

🔥 Why You Should Learn Go

High performance (close to C++)
Simple syntax
Great for backend + APIs
Used by companies like Google, Uber, Netflix

🧭 Coming Next

In upcoming posts, I’ll cover:

Building REST APIs in Go
Connecting Go with PostgreSQL
Using Go with Docker
Concurrency deep dive (goroutines + channels)

💬 Final Thought

If you already know backend development, Go will feel like a power upgrade.

Start small. Stay consistent. Share what you learn.

golang #backend #programming #webdev #devto

🚀 5 Modern PHP Features You Should Start Using Today

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:03:48 +0000

If you’re still writing PHP like it's 2015, you're missing out on some powerful features that make your code cleaner, safer, and easier to maintain.

In this post, I’ll walk you through 5 modern PHP features in a very simple way — with examples you can actually use in real projects.

1. ✅ Typed Properties (Strict Data Handling)

Before PHP 7.4, you couldn’t define types for class properties.

❌ Old way:

class User {
    public $name;
}

✅ New way:

class User {
    public string $name;
}

Why it matters:

Prevents invalid data
Makes your code predictable
Helps avoid bugs early

2. ✅ Arrow Functions (Shorter Closures)

Arrow functions make your code shorter and cleaner.

❌ Old way:

$numbers = [1, 2, 3];

$squared = array_map(function($n) {
    return $n * $n;
}, $numbers);

✅ New way:

$squared = array_map(fn($n) => $n * $n, [1,2,3]);

Why it matters:

Less boilerplate
More readable functional code

3. ✅ Null Safe Operator (`?->`)

Avoid those annoying null checks.

❌ Old way:

if ($user && $user->profile) {
    echo $user->profile->email;
}

✅ New way:

echo $user?->profile?->email;

Why it matters:

Cleaner code
No more "trying to access property of null" errors

4. ✅ Match Expression (Better than switch)

match is more strict and cleaner than switch.

❌ switch:

switch($status) {
    case 'success':
        $msg = 'Done';
        break;
    case 'error':
        $msg = 'Failed';
        break;
}

✅ match:

$msg = match($status) {
    'success' => 'Done',
    'error' => 'Failed',
    default => 'Unknown'
};

Why it matters:

No break needed
Strict comparison (no type confusion)

5. ✅ Constructor Property Promotion

Less boilerplate when creating classes.

❌ Old way:

class User {
    public string $name;

    public function __construct($name) {
        $this->name = $name;
    }
}

✅ New way:

class User {
    public function __construct(public string $name) {}
}

Why it matters:

Cleaner classes
Less repetitive code

🔥 Final Thoughts

Modern PHP is:

Faster ⚡
Cleaner ✨
Safer 🔒

If you're working with frameworks like Laravel, these features are already being used under the hood — so understanding them will level up your coding skills.

💬 What Next?

If you found this useful, I can share:

Real-world Laravel examples using these features
Performance tips for PHP apps
Clean architecture patterns in PHP

Let me know in the comments 👇

PHP #Laravel #WebDevelopment #Backend #Programming

The Case of the Empty 500: How I Proved the API Failure Wasn't Our Fault

Ahmed Raza Idrisi — Wed, 11 Feb 2026 17:40:56 +0000

We’ve all been there. You make an API call, it fails, and the finger-pointing begins. "It’s the frontend," says the backend team. "It’s your service," says the API provider.

Recently, I faced a debugging challenge where our application was receiving an empty response from an external API. On the surface, it looked like our request was simply vanishing into the void. Here is how I tracked down the culprit: The WAF.

The Problem
Our application was calling an external endpoint. The symptoms were frustratingly vague:

Response Body: Completely empty.

Result: The application logic failed because there was no data to parse.

Internal Consensus: Initial thoughts were that our request payload was malformed or our connection was dropping.

Digging into the Headers
While the response body was empty, the HTTP Status Code and Response Headers told a different story. I noticed two red flags:

Status Code 500: A "500 Internal Server Error" usually implies the server tried to do something and failed. If it were our network, we’d likely see a 404 or a timeout.

Infrastructure Headers: Looking at the network trace, I saw headers related to Cloudflare and specific WAF (Web Application Firewall) signatures.

The "Aha!" Moment
By analyzing the custom headers injected by their WAF, I realized the request wasn't even reaching their application code. Their security layer was intercepting our request and dropping the payload before the server could process it.

Even though the body was empty, the presence of those specific infrastructure headers proved that the hand-off to their network was successful, but their security rules were blocking us.

The Resolution
I presented the logs and the specific WAF headers to the provider's network team. With this evidence, they were able to:

Identify the specific firewall rule that was flagging our IP/payload.

Whitelist our service.

Restore the API functionality.

Key Takeaways for Debugging APIs
Never ignore the headers: The body might be empty, but headers are the "fingerprints" of the servers the request passed through.

Status codes matter: A 500 error is a server-side confession.

Check for Middleware: In modern web dev, you aren't just talking to a server; you're talking to Load Balancers, WAFs, and Proxies.

laravel request life cycle

Ahmed Raza Idrisi — Fri, 26 Sep 2025 15:21:04 +0000

Laravel Request Lifecycle

The Laravel request lifecycle begins when a user sends an HTTP request to the web server (Apache, Nginx). The server forwards the request to the public/index.php file, the application's single entry point. This file loads Composer’s autoloader, performs essential bootstrapping, and constructs a new instance of the Laravel application.

The next step is the HTTP Kernel, which manages the request, response, and middleware stacks. The global middleware stack runs first, acting as filters for every HTTP request. Service providers register core services, and after bootstrapping, the router dispatches the request to a route or controller, executing any route-specific middleware.

Controllers (or route closures) process the request and generate a response—HTML view, JSON, download, or redirect. Before the response is sent to the user's browser, it passes back out through the middleware stack for any post-processing. Finally, the Kernel’s handle() method returns the response for index.php to deliver to the browser.

Middleware's Role in the Lifecycle

Middleware in Laravel act as filters operating before or after the core route/controller logic. They check authentication, log requests, manipulate headers, etc. Middleware can be global (applied to all requests) or route-specific (applied only to selected routes). Middleware can halt, redirect, modify requests, or even process responses before they're sent back to the client.

Creating Custom Middleware

Global Middleware

Generate middleware: php artisan make:middleware CustomGlobalMiddleware.[8]
Add logic in app/Http/Middleware/CustomGlobalMiddleware.php:

  public function handle($request, Closure $next)
  {
      // Custom logic here
      return $next($request);
  }

  protected $middleware = [
      // ... existing middleware,
      \App\Http\Middleware\CustomGlobalMiddleware::class,
  ];

Now the middleware runs for every HTTP request.

Route Middleware

Generate middleware: php artisan make:middleware CustomRouteMiddleware.
Add logic in app/Http/Middleware/CustomRouteMiddleware.php as above.
Register in app/Http/Kernel.php within $routeMiddleware:

  protected $routeMiddleware = [
      'custom' => \App\Http\Middleware\CustomRouteMiddleware::class,
  ];

Apply to route:

  Route::get('/example', function () {
      return 'Example Route';
  })->middleware('custom');

For groups:

  Route::middleware(['custom'])->group(function () {
      Route::get('/a', ...);
      Route::get('/b', ...);
  });

Passing Parameters to Middleware

Parameters can be sent to route middleware by appending them after a colon in the route definition:

Route::get('/post/{id}', 'PostController@show')->middleware('verify.role:admin');

In the middleware class, receive them as extra arguments:

public function handle($request, Closure $next, $role)
{
    // Check for required role
    return $next($request);
}

To access route parameters (like {id}) inside middleware:

$id = $request->route('id'); // Gets route param 'id'
$params = $request->route()->parameters(); // All parameters array

This lets you make your middleware context-aware and dynamic.

Quick Reference Table: Request Lifecycle Steps

Step	Purpose
Web Server	Receives & forwards HTTP request
index.php	Application entry, bootstraps Laravel
Kernel	Handles requests, global middleware
Service Providers	Register services
Router	Routes requests, applies route middleware
Controller/View	Core logic & generates response
Middleware	Filters/Processes requests & responses
Response	Sent back via Kernel & index.php

This sequence gives a robust, hands-on understanding of where middleware intercepts requests, how to build custom ones, and how parameters integrate with the lifecycle—all as essential for mastering Laravel’s request flow and middleware.

Replication & High Availability

Ahmed Raza Idrisi — Sat, 20 Sep 2025 06:15:42 +0000

Replication & High Availability

🔹 What is Replication?

Replication is the process of copying data from one database server (the primary) to one or more other servers (replicas/secondaries).

The primary (or master) handles writes (INSERT, UPDATE, DELETE).
The replicas (or slaves, followers, standbys) receive these changes and apply them.
This ensures multiple copies of the same data exist across servers.

👉 Think of it like keeping photocopies of your important notebook in multiple places — if one is lost, you still have backups.

🔹 Types of Replication

Synchronous Replication

Writes on the primary are confirmed only after replicas also confirm they’ve written the change.
Ensures no data loss but can slow down performance (since it waits).
Example: PostgreSQL synchronous replication.

Asynchronous Replication

Primary writes immediately return success, and replicas catch up later.
Faster, but risk of data loss if primary crashes before replicas sync.
Example: MySQL’s default replication.

Semi-synchronous Replication

A middle ground: primary waits for at least one replica to confirm before success.
Balance between safety & performance.

🔹 Why Replication is Important?

Read Scaling: Distribute reads across replicas (read-heavy apps benefit).
High Availability: If primary fails, replicas can be promoted as new primary.
Disaster Recovery: Data is safe even if one server is lost.
Geographic Distribution: Users in Asia can read from an Asia replica instead of a US server.

🔹 High Availability (HA)

HA is about keeping your database always online, even during failures. Replication is a core building block of HA, but HA adds automatic failover and monitoring.

If primary dies, a replica automatically becomes the new primary.
Clients reconnect automatically without manual intervention.
Requires a cluster manager / orchestrator.

🔹 Replication & HA in Popular Databases

MySQL
- Replication: Asynchronous by default (binlog-based).
- HA: Tools like MySQL InnoDB Cluster, Orchestrator, or ProxySQL handle failover.
PostgreSQL
- Built-in streaming replication.
- HA: Tools like Patroni, PgBouncer, repmgr, or Stolon.
MongoDB
- Replica sets built-in: one primary, multiple secondaries, automatic failover.
Cassandra
- Replication is peer-to-peer (no master/replica distinction). Every node can handle writes.

🔹 Example Scenario

Imagine a banking app:

Primary DB (Mumbai) → handles all deposits/withdrawals.
Replicas:
- Delhi replica → handles read queries for North India users.
- London replica → handles reads for European users.

If the Mumbai primary crashes:

Delhi replica is promoted to new primary.
All writes now go to Delhi, ensuring zero downtime for customers.

✅ Summary
Replication = Copying data across servers.
High Availability = Making sure the database stays alive automatically, even if one server dies.

🔹 How Automatic Failover Works

1. Health Monitoring

Tools like Patroni (PostgreSQL), Orchestrator (MySQL), or MongoDB built-in replica sets constantly ping the primary DB.
They check:
- Is the DB server alive (via TCP/heartbeat)?
- Is replication up-to-date?
- Is there network partition (primary is alive but unreachable)?

👉 If the primary stops responding within a certain timeout (say 10s), it’s marked as failed.

2. Leader Election

In a cluster, you don’t want two primaries (split-brain issue ⚠️).
A consensus system like Etcd, Consul, or Zookeeper is used.
Cluster members vote:
- "Primary is dead, we need a new one."
- They agree on which replica is most up-to-date.

👉 The most recent replica (with the least replication lag) becomes the new Primary.

3. Failover / Promotion

The chosen replica:
- Promotes itself to Primary.
- Stops being read-only.
- Starts accepting writes.

👉 In Patroni (PostgreSQL), this is done with pg_ctl promote.
👉 In Orchestrator (MySQL), it issues RESET SLAVE ALL + reconfigures replication.

4. Reconfiguration

Other replicas now start replicating from the new Primary.
The cluster updates routing so apps know where to send writes.
Tools like HAProxy, ProxySQL, or PgBouncer help by pointing apps to the current Primary.

5. Application Transparency

Applications don’t have to know which DB is Primary.
They just connect to a load balancer / proxy.
If failover happens, the proxy redirects traffic to the new Primary.

👉 This ensures no downtime for the app.

🔹 Example with Tools

PostgreSQL + Patroni
- Patroni uses Etcd/Consul for cluster state.
- Monitors DB health.
- On failure → promotes replica → updates routing.
MySQL + Orchestrator
- Continuously monitors replication topology.
- Detects primary failure.
- Promotes the best replica automatically.
- Updates HAProxy/ProxySQL.
MongoDB Replica Set
- Built-in heartbeat detection.
- Automatic election (no external tool needed).
- One secondary becomes new primary.

✅ Summary in Simple Words
Failover tools are like a traffic cop:

Check if the main road (primary DB) is open.
If closed, find the best alternative road (replica).
Redirect all cars (applications) automatically.

Advance Indexing in MYSql and Psql

Ahmed Raza Idrisi — Fri, 19 Sep 2025 12:25:42 +0000

Perfect 👌 Let’s go deep into Indexing since it’s the heart of database performance.
I’ll keep it detailed but easy to follow with MySQL & PostgreSQL examples.

🔹 Advanced Indexing Explained

Indexes are like the table of contents in a book 📖.

Without index → You scan the whole book to find “Chapter 10”.
With index → You jump directly to the page number listed.

In databases, indexes speed up SELECT queries by avoiding full table scans.

1. B-Tree Index (Default in MySQL & PostgreSQL)

Most common type.
Great for equality (=) and range queries (<, >, BETWEEN).
Data stored in a balanced tree → lookup is O(log n).

Example (Postgres/MySQL):

CREATE INDEX idx_users_email ON users(email);

Query using it:

SELECT * FROM users WHERE email = 'abc@gmail.com';

👉 Index lets DB jump directly to matching rows instead of scanning all.

2. Hash Index

Only good for exact matches (=).
Not good for ranges (<, >, BETWEEN).
MySQL has them in Memory engine; PostgreSQL supports HASH explicitly.

Example (Postgres):

CREATE INDEX idx_users_username_hash ON users USING HASH(username);

👉 WHERE username = 'john_doe' becomes super fast.

3. GIN Index (Generalized Inverted Index – PostgreSQL only)

Used for full-text search and JSONB queries.
Stores a mapping from value → rows containing it.

Example: Full-text search

CREATE INDEX idx_post_content_gin ON posts USING GIN(to_tsvector('english', content));

Query:

SELECT * FROM posts WHERE to_tsvector('english', content) @@ to_tsquery('database & scaling');

👉 Useful for search features (like Google inside your DB).

4. GiST Index (Generalized Search Tree – PostgreSQL)

More flexible than B-Tree.
Supports geospatial queries, ranges, similarity search.

Example (find locations near a point):

CREATE INDEX idx_locations_gist ON locations USING GiST(geom);

Query:

SELECT * FROM locations
WHERE ST_DWithin(geom, ST_MakePoint(77.5946, 12.9716)::geography, 5000);

👉 Finds all locations within 5km of given coordinates (great for maps).

5. BRIN Index (Block Range Index – PostgreSQL)

Very lightweight.
Instead of indexing every row, it stores min/max per block of rows.
Great for sequential / time-series data.

Example:

CREATE INDEX idx_logs_date_brin ON logs USING BRIN(log_date);

👉 Efficient for queries like:

SELECT * FROM logs WHERE log_date BETWEEN '2025-01-01' AND '2025-01-31';

👉 Works best when data is naturally ordered (like timestamps).

6. Covering Index (a.k.a. Index with INCLUDE columns)

Stores extra columns in the index itself.
Avoids going back to the table (called “index-only scan”).

Postgres:

CREATE INDEX idx_orders_customer_date
ON orders(customer_id) INCLUDE(order_date, total_amount);

Now:

SELECT customer_id, order_date, total_amount
FROM orders WHERE customer_id = 123;

👉 DB serves query only from index, no table lookup needed.

7. Partial / Filtered Index

Index only rows that meet a condition.
Saves space & improves performance when you query subsets often.

Postgres:

CREATE INDEX idx_active_users ON users(email) WHERE status = 'active';

👉 Queries on active users become lightning fast, without indexing inactive ones.

8. Expression Index

Index on a function or expression.
Great when queries always apply transformations.

Postgres:

CREATE INDEX idx_lower_email ON users(LOWER(email));

Now:

SELECT * FROM users WHERE LOWER(email) = 'abc@gmail.com';

👉 Uses index instead of scanning all rows.

🔹 How to Know Which Index to Use?

Exact match lookup → Hash index (Postgres) or B-Tree.
Range queries (>, <, BETWEEN) → B-Tree.
Text search / JSONB search → GIN.
Geospatial / similarity → GiST.
Time-series / ordered data → BRIN.
Only certain rows → Partial index.
Always lowercase/transform → Expression index.

🔹 Important Notes

Indexes speed up reads but slow down writes (inserts/updates/deletes need to update indexes).
Too many indexes = slower writes + more storage.
Always use EXPLAIN or EXPLAIN ANALYZE to see if your query uses the index.

✅ Summary:
Indexes are like shortcuts — different types exist for different problems.
Mastering them = 80% of database optimization as a database engineer.