Forem: Silva Chijioke Michael

"depends_on" vs "wait-for-it.sh" in Docker Compose

Silva Chijioke Michael — Thu, 25 Sep 2025 05:21:08 +0000

When working with multi-container setups (for example, an application and a database), it’s important to understand the difference between container startup order and service readiness.

`depends_on`

Ensures a container starts before another.
Example: Your app won’t start until the database container has been launched.
Limitation: It does not guarantee the database is ready to accept connections.

`wait-for-it.sh`

A lightweight shell script that makes one service wait until another is reachable (via TCP).
Example:

CMD ["wait-for-it", "db:5432", "--", "npm", "start"]

This ensures the app starts only after Postgres is ready.

Visual Comparison

Without wait-for-it.sh:

App ----> tries DB   [DB not ready]   → fails

With wait-for-it.sh:

App ----> waits ----> DB ready        → starts successfully

Why prefer `wait-for-it.sh` (or similar scripts)?

Prevents race conditions such as applications crashing on startup.
Works across any service (databases, caches, APIs).
Simple, portable, and avoids complex retry logic in your application code.

Summary

Use depends_on for container startup order.
Use wait-for-it.sh (or healthchecks) for service readiness.

This small distinction saves time, prevents bugs, and ensures smoother container orchestration.

Ensuring Idempotency in Distributed Systems – Lessons from Go & GCP

Silva Chijioke Michael — Mon, 25 Aug 2025 05:11:04 +0000

In distributed systems, failures happen — network glitches, retries, or even duplicate requests. Without proper handling, this can lead to unintended side effects like multiple charges, duplicated tasks, or inconsistent states.

This is where idempotency comes in.

Idempotency means that performing the same operation multiple times produces the same result, no matter how many retries occur. Think of pressing an elevator button — pressing it once or ten times doesn't make the elevator arrive faster; the action has the same effect.

Recently, we refactored parts of our system to ensure idempotency across critical operations. Using Go and Google Cloud Platform (GCP) services like Pub/Sub, we introduced queues and deduplication strategies that guarantee:

No duplicate processing: We track request IDs to ensure each request is processed only once.

Safe retries: If a worker crashes or a request times out, retries don't break consistency.

Deterministic outputs: The same inputs always produce the same result.

A few lessons learned:

Design for retries: Assume every call may happen more than once.

Use queues: use queues with at-least-once delivery (e.g., Pub/Sub) but build deduplication logic into your service.

Keep business logic deterministic: avoid side effects like random values unless controlled.

Implementing idempotency might feel like extra work, but it’s essential for building resilient, fault-tolerant systems, especially at scale.

Have you implemented idempotency in your APIs or distributed workflows? How did you handle retries and deduplication?

Solving simple time based problems with go lang.

Silva Chijioke Michael — Mon, 13 May 2024 11:25:33 +0000

so interestingly i was assigned a task i really enjoyed, this had to do with repeatedly looping over a set of documents in the db, making some transactions and finally updating documents based on certain conditions.
The first idea was to use a Cron Job(well obviously) everyone knows what a cron job does, but interestingly the problem was to be solved using Go Lang which is one of our stacks on my current team.

I shared the problem with the backend team and we discussed different methods to approach the problem and at the end of the day it boiled down to setting up a cron job that runs repeatedly at “x time” or using the Go timer package.

I used the go timer package and i used it mainly for two reasons:

Ease of use: it was already pre-installed, easy to use and provides a plethora of methods and properties that could be used to solve basically all the problems presented on a low level (it gives total control)
Less complexity: I was already using go lang, there was no real need to install a separate package to over engineer a somewhat simple problem.

Here’s a simple snippet of how to solve the same type of problem:

We define our timed funtion for this example we'll be using the go MongoDB and mux router

// assuming we want the function to run at 12am daily
func initTimer(conn *db.MongoDB, router *mux.Router) {
    currentTime := time.Now()

    // Calculate the duration until 12 AM
    desiredTime := time.Date(currentTime.Year(), currentTime.Month(), currentTime.Day(), 0, 0, 0, 0, currentTime.Location())
    if desiredTime.Before(currentTime) {
        // If 12AM has already passed today, schedule it for 12AM tomorrow
        desiredTime = desiredTime.Add(24 * time.Hour)
    }

    // Calculate the duration until the 12AM
    duration := desiredTime.Sub(currentTime)

    // Wait until it's time to execute the function
    <-time.After(duration)
    go ourTransaction(conn, router)
}

func ourTransaction(conn *db.MongoDB, router *mux.Router) {
   entity := pkg.InitTrxn(conn, router) //init package


    //initial transaction to counter build during updates (optional)
    go entity.RunTrxn()

    // re-run this function every 24hrs by setting up a new ticker using the "time.NewTicker" function
    var ticker *time.Ticker = time.NewTicker(24 * time.Hour)

    //repeat actions at intervals using the "ticker.C" field
    for tickTime := range ticker.C {
        go entity.RunTrxn() // a resource intensive function
        log.Println("i'm running at time:", tickTime)
    }
}

We initialize the timed functions in our main.go package

func main(){
// initialize 
    go initTimer(dbConn, router) // run on a separate thread 
}

In my case the the transaction needed me to make an update base on last action time (..actally i just want to show more stuff done with the go timer package 😏).

package packageName

func (t trxnStruct) RunTrxn() {
       items, err := t.GetAllItems()
       if err != nil{
          log.Panicf("Error at getting items %s", err)
          }

       for _, item := range items {

       // get time difference between last transaction time  and current time using the "time.since" function
         timeDifferenceSinceLastTrxn = time.Since(item.LastTransactionTime)

        inActiveDays := int(timeDifferenceSinceLastTrxn.Hours() / 24) //convert to days
        item.InActiveDays = inActiveDays
         maxdaysofInactivity := 10 

        if item.InActiveDays > maxdaysofInactivity{
           item.Status = constants.INACTIVE 
          }

        t.UpdateItem(item.ID, item) // repo funtion to update DB Record

      }
   return
}

In conclusion, the go timer package is a robust and yet easy to use package with a lot of useful tools to help solve your time based based problems. you can find more info from the docs [https://pkg.go.dev/time]

How I built a multiplayer game with no backend

Silva Chijioke Michael — Tue, 05 Dec 2023 19:48:50 +0000

Crafting Multiplayer X and O Game: A WebSuckit Adventure

Abstract

Join me on a journey into the world of multiplayer online games as we dive into creating a WebSocket-powered tic-tac-toe game. This article aims to demystify the process and provide a hands-on guide for building a real-time gaming experience.

Introduction

Picture this: You built a game about two, three years ago as a yearly vanilla javascript refresher. This was a simple tic-tac-toe game that manipulated arrays, objects, and the browser Dom and this was forgotten somewhere in your GitHub with a "To Do" comment that read "Make this a multiplayer Game".

Fast forward a couple of months into 2023, you reached out to a couple of friends and you get to find out they've been working on a duplex communication platform for developers and there's a need for example projects, and voila! out of the plethora of unfinished chat apps, you remember the "To Do" comment this was almost as perfect as Lee laying that first kick on Gara's head in the season 1 of the Naruto series.

Let's Set the Scene

Before we jump into the coding magic, let's set the stage. Why WebSocket, you ask? Well, WebSocket enables seamless communication between clients and servers, making it ideal for creating responsive and interactive multiplayer games but then I had no intentions of setting up a backend server for the project, I didn't even run a 'node init'.

The Challenge

There were three major challenges, the first was setting up a connection to the native websocket server, the second was managing the logic for the first connection between the initializer and others joining using his URL, and finally managing and communicating disconnections.

The Tech Behind the Magic

WebSuckit 101

First things first, let's get familiar with the star of the show: WebSuckIt. This section serves as your crash course, so buckle up.

Setting Up the Playground

Time to get our hands dirty. We'll set up the environment, initialize the game engine, and lay the foundation for our multiplayer masterpiece.

firstly we introduced our package in our HTML file

    <script src="https://unpkg.com/@websuckit/js/dist/websuckit.umd.js"></script>

Next, we instantiate a websuckit class, to do this we simply had to create an account on websuckit.

navigated to our profile and copied out the necessary credentials required to initialize our class.

const config = {
  PUBLIC_KEY: "your public key",
  USER_ID: "your user ID",
  ACCESS_KEY: "your access key",
};

//ws - Our websuckit class 
const ws = new Websuckit({
  userId: config.USER_ID,
  accessKey: config.ACCESS_KEY,
  publicKey: config.PUBLIC_KEY,
});`

The Gameplay

With the stage set and the tech in place, let the gameplay commence. We'll break down the technical details into bite-sized chunks, exploring each aspect of our game.

Player X vs. Player O

Delve into the intricacies of player interactions. How does the game react when Player X makes a move? How about Player O? We've got it covered.

The Thrill of Victory, the Agony of Defeat

Explore the logic behind determining a winner or declaring a draw. After all, every game needs a champion.

Bringing It to Life

Enough theory; let's bring our creation to life. Follow along as we implement the game, step by step. By the end, you'll have a functioning multiplayer tic-tac-toe game to call your own.

What's in It for You?

Wondering why you should embark on this WebSocket adventure? We'll uncover the benefits, the skills you'll gain, and the sheer joy of seeing your creation in action.

Challenges and Lessons

Every adventure comes with its challenges. We'll navigate through potential pitfalls and share the lessons learned along the way.

Conclusion

As our WebSocket journey comes to an end, take a moment to reflect on the incredible world of real-time gaming you've just stepped into. Cheers to the countless multiplayer adventures that lie ahead!

Join the Fun

Ready to embark on your WebSocket journey? Dive into the code, explore the nuances, and bring your own twist to this multiplayer gaming saga. Let the games begin!

About the Author

Meet [Your Name], a passionate developer with a knack for turning complex concepts into engaging adventures. Connect on [LinkedIn/Twitter/GitHub] for more coding escapades.

Feel free to personalize and adapt this template to match your style and the specific details of your WebSocket gaming experience. Happy writing!