Forem: Rokibul Hasan

Why Our AWS RDS Cost Suddenly Spiked and How We Saved ~40%

Rokibul Hasan — Wed, 31 Dec 2025 15:57:24 +0000

Our AWS RDS cost jumped unexpectedly over the last 2 days, even though usage and traffic were unchanged.

What went wrong?

After a deep dive, we found the root cause:
👉 Our Reserved DB Instance (RI) had expired.

Once the RI expired, the database automatically fell back to On-Demand pricing, which is significantly more expensive.

The fix

We immediately purchased a new Reserved DB Instance matching:

PostgreSQL
Instance class
Multi-AZ
Region

This was a billing-only change:

No downtime
No restarts
No configuration changes

The result

💰 ~30–40% reduction in DB instance cost

📉 Monthly spend became predictable again

⚡ Savings applied instantly

Key takeaway
RI expirations are silent, but their cost impact is immediate.

Always monitor:

RI expiration dates
Cost Explorer anomalies
Billing alerts

A missed RI renewal can cause instant cost spikes, even for stable workloads.

🧠 Learning Thanos (No, Not the Purple Villain)

Rokibul Hasan — Sat, 31 May 2025 09:44:29 +0000

Hey everyone! 👋

This week I spent some time learning about Thanos — not the Marvel villain, but the one that works with Prometheus for monitoring in Kubernetes.

I’ll be honest — when I first heard about Thanos, I thought “Sounds complicated.”
And you know what? It kind of is… but it’s also super useful once you get the hang of it.

I didn’t build anything fancy, but I did get a minimal setup working: Prometheus + Thanos Sidecar + MinIO + a simple Go app exporting custom metrics. Along the way, I picked up a few interesting lessons worth sharing.

🌐 What Even Is Thanos?

If you’re using Prometheus for monitoring, Thanos helps you:

Store metrics for a long time (not just a few days).
Query metrics across multiple Prometheus instances.
Avoid duplicate data if you’re running Prometheus in high availability mode.

Basically: it makes Prometheus smarter, stronger, and more scalable. Think of it like giving Prometheus a cloud brain.

🧪 What I Tried

Here’s what I set up (with a lot of Googling and head-scratching):

Sidecar: This sits next to Prometheus and helps upload data to a bucket (like S3).
Store: Reads data back from that bucket when you want to query old metrics.
Query: Lets you run PromQL queries across all your data — even from multiple clusters.
Compactor: Cleans up and organizes your stored metrics data.

📌 Why I’d Use Thanos Again

If you:

Use Prometheus for metrics.
Need to keep metrics longer than a few days.
Or want to monitor multiple clusters. …Thanos is worth checking out. It takes some time to get it running, but the payoff is great once you do.

🚀 Want to Try It Yourself?

If you're curious and want to spin it up yourself, I’ve the whole setup here:
👉 GitHub Repo: github.com/RokibulHasan7/thanos-demo

It includes all the manifests to deploy:

Prometheus.
Thanos Sidecar, Compactor, Store, and Query.
MinIO as the object store.
The demo Go app exposing metrics.

You’ll find step-by-step instructions in the README to try everything locally.

2024: Leveling Up My Tech Knowledge

Rokibul Hasan — Mon, 25 Dec 2023 18:41:30 +0000

The new year is on the horizon, and with it comes the exciting opportunity to reinvigorate our goals and push ourselves towards new heights. As a developer, I'm all about continuous learning and expanding my skillset to stay ahead of the curve. So, for 2024, I'm setting my sights on three key areas that will take my development game to the next level:

Mastering the Art of System Design:

System design is the magical glue that holds complex software architectures together. It's about understanding the big picture, making crucial decisions about scalability, reliability, and performance, and then translating those decisions into concrete technical choices. In 2024, I'm diving headfirst into this essential skill. I'll be devouring books like "Designing Data-Intensive Applications" by Martin Kleppmann and "Distributed Systems for Fun and Profit" by Martin Fowler. Online courses, tutorials, and hands-on practice building toy systems will also be on the menu. By the end of the year, I aim to confidently craft robust and efficient architectures that can handle any challenge.

Building Microservices Magic:

Microservices are all the rage, and for good reason. This architectural style breaks down monolithic applications into smaller, independent services that communicate with each other via APIs. The benefits are numerous: increased agility, resilience, and scalability. In 2024, I'm going beyond theory and getting my hands dirty building one or two real-world microservices projects. This will involve choosing the right technologies (think Spring Boot, Docker, and Kubernetes), designing APIs, and implementing communication protocols. The thrill of watching independent services seamlessly work together to achieve a larger goal is something I can't wait to experience.

DevOps Deep Dive:

DevOps is the bridge between development and operations, ensuring smooth collaboration and efficient software delivery. In 2024, I'm planning a deep dive into this crucial domain. I'll be mastering tools like Git, CI/CD pipelines, containerization technologies, and infrastructure as code. Understanding how to automate deployments, manage configurations, and monitor applications will be my key focus. By the end of the year, I want to be able to confidently say, "I can deploy and manage software like a pro!"

These three goals, while ambitious, are also incredibly exciting. They promise to open up new avenues for creativity, problem-solving, and career growth. As I embark on this journey, I'm sure to encounter challenges and roadblocks. But with dedication, perseverance, and a healthy dose of caffeine, I know I can achieve my goals and emerge a stronger, more versatile developer.

So, here's to 2024, a year of learning, building, and pushing boundaries. Who's with me?

I encourage you to share your own tech goals for the new year in the comments below. Let's support and inspire each other as we embark on our individual journeys of growth!

Remember, the key to success is to have a clear vision, a well-defined plan, and the unwavering determination to see it through. Happy coding, and here's to a fantastic 2024!

Designing an API in Go: Best Practices and Examples

Rokibul Hasan — Sun, 15 Jan 2023 05:23:33 +0000

Golang, also known as Go, is a programming language developed by Google. It is known for its simplicity, efficiency, and strong support for concurrent programming. When designing an API (Application Programming Interface) in Go, there are several principles to keep in mind to ensure that the API is easy to use and maintain.

Principles

One important principle is to make the API easy to read and understand. This can be achieved by keeping the API simple and having clear and consistent naming conventions. For example, instead of using complex and generic names for functions and variables, use clear and specific names that accurately describe their purpose. This will make it easier for developers to understand how the API works and how to use it.

Another principle is to use Go's built-in concurrency features to make the API efficient and scalable. Go's concurrency model is based on goroutines and channels, which allow for efficient and lightweight concurrent execution of code. By using these features, an API can handle a large number of requests without incurring a significant performance penalty.

It's also important to make the API easy to test and debug. Go provides a built-in testing framework and a number of third-party testing libraries that make it easy to write and run tests for an API. In addition, Go's error handling mechanism, which allows for returning explicit error values, makes it easy to identify and fix bugs in the API.

Another important principle is to use Go's built-in interfaces to make the API flexible and easy to extend. Go's interface system allows for decoupling the implementation of an API from its interface, making it easy to swap out different implementations without affecting the rest of the code. By designing the API with interfaces in mind, it becomes easy to add new features or make changes to the API without having to make major modifications to the codebase.

Lastly, it's important to design the API with good documentation in mind. Go has built-in support for inline documentation, which can be automatically extracted and used to generate documentation for the API. In addition, by providing clear and comprehensive documentation, developers will have an easier time understanding how to use the API and how to troubleshoot any issues they may encounter.

Example:

Here's an example of an API in Go that implements these principles:

package main

import (
    "fmt"
)

type UserService interface {
    GetUser(id int) (*User, error)
    CreateUser(user *User) error
    UpdateUser(user *User) error
    DeleteUser(id int) error
}

type User struct {
    ID int
    Name string
    Email string
}

type userService struct {
    users map[int]*User
}

func (s *userService) GetUser(id int) (*User, error) {
    user, ok := s.users[id]
    if !ok {
        return nil, fmt.Errorf("user with id %d not found", id)
    }
    return user, nil
}

func (s *userService) CreateUser(user *User) error {
    if _, ok := s.users[user.ID]; ok {
        return fmt.Errorf("user with id %d already exists", user.ID)
    }
    s.users[user.ID] = user
    return nil
}

func (s *userService) UpdateUser(user *User) error {
    if _, ok := s.users[user.ID]; !ok {
        return fmt.Errorf("user with id %d not found", user.ID)
    }
    s.users[user.ID] = user
    return nil
}

func (s *userService) DeleteUser(id int) error {
    if _, ok := s.users[id]; !ok {
        return fmt.Errorf("user with id %d not found", id)
    }
    delete(s.users, id)
    return nil
}

func main() {
    // Initialize userService
    service := &userService{
        users: make(map[int]*User),
    }
    // Example usage
    user1 := &User{ID: 1, Name: "John Doe", Email: "johndoe@example.com"}
    err := service.CreateUser(user1)
    if err != nil {
        fmt.Println(err)
    }
    user, err := service.GetUser(1)
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Println("Name:", user.Name)
    }
    user1.Name = "Jane Doe"
    err = service.UpdateUser(user1)
    if err != nil {
        fmt.Println(err)
    }
    user, err = service.GetUser(1)
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Println("Name:", user.Name)
    }
    err = service.DeleteUser(1)
    if err != nil {
        fmt.Println(err)
    }
}

Explanation of Code

This code defines a struct userService that implements the UserService interface and a struct User that holds the user's information. The struct userService has a map of users as one of its fields, this is a simple way of storing the data in memory, but in a real-world scenario, you would likely use a database or another more robust storage solution.
The userService struct has methods such as GetUser, CreateUser, UpdateUser, and DeleteUser, which correspond to basic CRUD operations. These methods make use of Go's error handling mechanism by returning explicit error values, making it easy to identify and fix bugs in the API.
In the main function, an instance of userService is created and initialized, and examples of how to use the API are given. The example shows how to create a new user, get a user by ID, update a user and delete a user by ID.

It is important to note that this is a very simple example and it does not cover all the aspects of a real world API but it serves as a good starting point to understand the basic principles of designing an API in Go.

Go Pro Tips: Mastering Arrays and Slices for Efficient Data Management

Rokibul Hasan — Thu, 29 Dec 2022 14:40:49 +0000

In the Go programming language, arrays and slices are both used to store collections of data. However, there are some key differences between the two that can impact how you use them in your code.

Array

An array is a fixed-size collection of elements of the same type. Once you create an array, you cannot change its size. Here's an example of how you might declare and initialize an array in Go:

Slice

On the other hand, a slice is a dynamically-sized, flexible view into the elements of an array. You can think of a slice as a window that you can move over the elements of an array. You can create a slice using the "make" function, or by using the "array[start:end]" syntax. Here's an example of how you might create a slice in Go:

One thing to keep in mind when working with slices is that they can be created with a capacity that is larger than their length. This means that you can append new elements to the slice without having to create a new underlying array every time the slice grows beyond its current capacity. To create a slice with a specific capacity, you can use the "make" function with a third argument:

This creates a slice with a length of 0 and a capacity of 5. You can then append elements to the slice until it reaches its capacity, at which point a new underlying array will be created and the elements will be copied over.

You can also use the "append" function to grow a slice by appending one or more elements to the end of it. For example:

This will add the elements 4, 5, 6, and 7 to the end of the slice "d".

Another useful feature of slices is that you can use the "copy" function to copy the elements of one slice into another. For example:

This will copy the elements of slice "e" into slice "d", replacing the existing elements.

Differences between Array and Slice

One key difference between arrays and slices is that slices are more flexible and easier to work with in most cases. Because slices are dynamically sized, you can easily append new elements to them or remove elements from them without having to worry about resizing the underlying array. In contrast, if you want to change the size of an array, you must create a new array and copy the elements over.

Another difference is that slices are reference types, while arrays are value types. This means that when you pass a slice to a function or assign it to a new variable, you are actually passing a reference to the underlying array. In contrast, when you pass an array to a function or assign it to a new variable, a new copy of the array is created.

When should you use an array and when should you use a slice?

In general, you should use a slice whenever possible because it is more flexible and easier to work with. However, there are a few situations where you might want to use an array instead:

When you need to store a large amount of data and you want to minimize the overhead of creating and managing slices.
When you need to pass an array to a function that expects a fixed-size array as an argument.
When you need to create a multidimensional array and you want to use a syntax like "array[i][j]" to access the elements.

Here's an example of how you might use an array and a slice in Go to store and process a list of integers:

Conclusion

I hope this helps give you a better understanding of the differences between arrays and slices in Go, and how to use them effectively in your code. As a general rule, you should use slices whenever possible because of their flexibility and ease of use, but don't hesitate to use arrays when you have specific needs that can't be met with slices.