Building High-Performance REST APIs with Go and Fiber

Why Go + Fiber in 2026

I've built APIs in Node.js, Python, Java, and Go. For the last 3 years, I've chosen Go + Fiber for every single production API project. Here's why:

• Raw speed: Fiber benchmarks at 200K+ req/s on a basic VPS. That's 5-10x faster than Express.js and 3-5x faster than FastAPI.
• Low memory: A Fiber API serving 10K concurrent connections uses ~50MB RAM. The equivalent Node.js app? ~500MB.
• Simple deployment: Single binary. No runtime dependencies. Copy to server, run. Done.
• Go's type system: Catch errors at compile time, not in production at 3 AM.

Project Structure

Here's the structure I use for every production API:

project/
├── cmd/
│   └── server/
│       └── main.go
├── internal/
│   ├── handler/        # HTTP handlers
│   ├── service/        # Business logic
│   ├── repository/     # Database queries
│   ├── model/          # Data structures
│   └── middleware/     # Auth, logging, etc.
├── pkg/
│   └── response/       # Shared utilities
├── migrations/
├── config/
├── docker-compose.yml
└── Dockerfile

The Core Setup

package main

import (
    "log"
    "os"
    
    "github.com/gofiber/fiber/v2"
    "github.com/gofiber/fiber/v2/middleware/compress"
    "github.com/gofiber/fiber/v2/middleware/cors"
    "github.com/gofiber/fiber/v2/middleware/limiter"
    "github.com/gofiber/fiber/v2/middleware/logger"
    "github.com/jmoiron/sqlx"
    _ "github.com/lib/pq"
)

func main() {
    db := initDB()
    defer db.Close()
    
    app := fiber.New(fiber.Config{
        AppName:      "MyAPI",
        ErrorHandler: customErrorHandler,
        ReadTimeout:  10 * time.Second,
        WriteTimeout: 10 * time.Second,
    })
    
    // Middleware stack
    app.Use(logger.New())
    app.Use(compress.New(compress.Config{Level: compress.LevelBestSpeed}))
    app.Use(cors.New())
    app.Use(limiter.New(limiter.Config{
        Max:        100,
        Expiration: 1 * time.Minute,
    }))
    
    // Routes
    api := app.Group("/api/v1")
    
    // Public routes
    api.Post("/auth/login", handlers.Login(db))
    api.Post("/auth/register", handlers.Register(db))
    
    // Protected routes
    protected := api.Use(middleware.Authenticate())
    protected.Get("/products", handlers.ListProducts(db))
    protected.Post("/products", handlers.CreateProduct(db))
    protected.Get("/products/:id", handlers.GetProduct(db))
    
    log.Fatal(app.Listen(":8080"))
}

Database Layer with sqlx

I prefer sqlx over GORM for performance-critical APIs. Here's why — and how I structure it:

type ProductRepository struct {
    db *sqlx.DB
}

func (r *ProductRepository) List(ctx context.Context, params ListParams) ([]Product, int, error) {
    var products []Product
    var total int
    
    // Count query
    countQuery := `SELECT COUNT(*) FROM products WHERE tenant_id = $1`
    err := r.db.GetContext(ctx, &total, countQuery, params.TenantID)
    if err != nil {
        return nil, 0, err
    }
    
    // Data query with cursor-based pagination
    query := `
        SELECT id, name, sku, price, stock, created_at
        FROM products
        WHERE tenant_id = $1
        ORDER BY created_at DESC
        LIMIT $2 OFFSET $3
    `
    err = r.db.SelectContext(ctx, &products, query, params.TenantID, params.Limit, params.Offset)
    if err != nil {
        return nil, 0, err
    }
    
    return products, total, nil
}

Performance Patterns

1. Connection Pooling

Never open a new database connection per request. Configure your pool properly:

db.SetMaxOpenConns(25)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(5 * time.Minute)
db.SetConnMaxIdleTime(3 * time.Minute)

2. Response Caching

Use Redis for frequently-accessed, rarely-changed data:

func GetProductsCached(ctx context.Context, rdb *redis.Client, repo *ProductRepository, params ListParams) ([]Product, int, error) {
    key := fmt.Sprintf("products:%s:page:%d", params.TenantID, params.Page)
    
    cached, err := rdb.Get(ctx, key).Bytes()
    if err == nil {
        var result CachedProducts
        json.Unmarshal(cached, &result)
        return result.Products, result.Total, nil
    }
    
    products, total, err := repo.List(ctx, params)
    if err != nil {
        return nil, 0, err
    }
    
    cacheData, _ := json.Marshal(CachedProducts{Products: products, Total: total})
    rdb.Set(ctx, key, cacheData, 5*time.Minute)
    
    return products, total, nil
}

3. Request Validation

Use go-playground/validator for fast, clean validation:

type CreateProductRequest struct {
    Name        string  `json:"name" validate:"required,min=3,max=100"`
    SKU         string  `json:"sku" validate:"required,alphanum"`
    Price       float64 `json:"price" validate:"required,gt=0"`
    Description string  `json:"description" validate:"max=1000"`
}

Benchmark Results

Here are real benchmarks from a production API I built for an e-commerce platform:

All on a Rp 500K/month 4-core VPS with PostgreSQL. No CDN, no load balancer.

The Gotchas

• Don't use time.Sleep for rate limiting. Use Fiber's built-in limiter middleware.
• Always set timeouts. Without them, one slow client can block your entire server.
• Use context.Context everywhere. It's your cancellation mechanism and timeout controller.
• Measure before optimizing. Add pprof endpoints and use benchstat for proper benchmarks.

Bottom Line

Go + Fiber gives you production-grade performance with minimal complexity. If you're building APIs for Indonesian businesses — especially ones that need to handle spikes during promo events or month-end processing — this stack will serve you well.