DEV Community: Nguyễn Long

From Polling to Partying: Writing Cooler Goroutines with sync.Cond

Nguyễn Long — Thu, 26 Jun 2025 02:38:14 +0000

TL;DR

Imagine a DJ show with hundreds of people waiting for their favorite track to drop. If everyone kept asking the DJ every millisecond:
"Is it time to dance yet? Now?"
You’d probably end up with:

A sweaty DJ (over loaded)
Burned speakers (crashing)
And a power outage (aka a CPU meltdown)

That’s what polling looks like in code.

But what if the DJ had a mic and just said:
"Hey! When the beat drops, I’ll tell you!"

That’s sync.Cond.

So, What is `sync.Cond`?

Go’s sync.Cond is a condition variable
a concurrency primitive that lets goroutines sleep efficiently while waiting for a condition to become true. It’s based on:

A shared mutex
A condition-checking loop
And the ability to wait, signal, or broadcast to other goroutines.

You use it when:

There’s a shared resource (like a connection pool or ticket list)
Goroutines must wait for that resource to become available
You want to avoid polling or wasting CPU

Take the example when you use Polling:

Imagine you’re running a party where guests (goroutines) can only enter the dance floor when there’s space.

for {
    if showReady {
        fmt.Println("💃 Fan starts dancing!")
        break
    }
    time.Sleep(100 * time.Millisecond)
}

They keep checking and sleeping... That’s like asking the DJ every 100ms:

"Hey, can I dance yet? What about now? How about now?!"
That’s called polling, and it’s inefficient and annoying (for both CPU and DJ).

Enter: sync.Cond – a way to wait without burning CPU until you're signaled to proceed.

So let's take a look at this example first, then we will dig deeply into the mechanism:

var mu sync.Mutex
cond := sync.NewCond(&mu)
showReady := false
// Fan goroutine
go func() {
    mu.Lock()
    for !showReady {
        fmt.Println("🧍 Fan waiting...")
        cond.Wait() // unlocks, sleeps, then relocks
    }
    fmt.Println("💃 Fan starts dancing!")
    mu.Unlock()
}()

// DJ goroutine
go func() {
    time.Sleep(3 * time.Second)
    mu.Lock()
    showReady = true
    fmt.Println("🎧 DJ: The beat drops!")
    cond.Signal() // wakes up one fan
    mu.Unlock()
}()

This example illutrates:

Let fans "wait" until the event is ready -> stimulate for 3 seconds
Notify waiting fans as soon as the DJ starts

Business Analogy

This pattern models real business use cases like:

Worker thread pools waiting for jobs
Order processors waiting for payment confirmation
Consumers waiting for items to appear in a queue
Background tasks triggered by external events

In our case:

The dance floor = the shared resource.
The fan = goroutine that waits.
The DJ = the event trigger.

Now let's talk about the correct way to use this mechanism:

This is the simple flow:

mu.Lock()
for !condition {
    cond.Wait()
}
doWork()
mu.Unlock()

like :

mu.Lock()
    for !showReady {
        fmt.Println("🧍 Fan waiting...")
        cond.Wait() // unlocks, sleeps, then relocks
    }
fmt.Println("💃 Fan starts dancing!")
mu.Unlock()

the flow will be depicted as bellow:

[🔒 LOCKED]        G1 enters critical section
[❓ CHECK ]       Check condition Is showReady true? -->No.
[😴 WAIT ]        G1 goes to sleep → cond.Wait() waiting for other GR to wake it up! (meaning waiting for the beat drops)
[🔓 UNLOCKED]     Lock is released while waiting

Another goroutine will signals:

mu.Lock()
condition = true
cond.Signal() // or cond.Broadcast()
mu.Unlock()

That's mean when the DJ drops the beat, game on...

go func() {
    time.Sleep(3 * time.Second)
    mu.Lock()
    showReady = true
    fmt.Println("🎧 DJ: The beat drops!")
    cond.Signal() // wakes up one fan
    mu.Unlock()
}()

by:

[🔒 LOCKED]       G2 changes condition to true (start the show) 
[📣 SIGNAL]       G2 calls cond.Signal() (notify to the FAN)
[🔓 UNLOCKED]     Lock released

Then:

[👂 WOKEN UP]     G1 is notified, wakes up 
[🔒 LOCK AGAIN]   Tries to reacquire the mutex
[✅ RECHECK ]     Sees condition is now true
[🏃 PROCEED ]     Does work and exits

The output looks like this:

🧍 Fan waiting...
🎧 DJ: The beat drops!
💃 Fan starts dancing!

Why not just `time.Sleep()`?

You could say: "Why not just let the fan sleep for 3 seconds too?"
Because in a real app:

The DJ doesn’t follow a fixed schedule.
There might be many fans, not just one.
The fan may give up waiting or be notified instantly the moment music starts.

How Does `Wait()` Actually Work?

Here’s the implementation under the hood:

func (c *Cond) Wait() {
    c.checker.check()                             // panic if copied
    t := runtime_notifyListAdd(&c.notify)         // get a wait ticket
    c.L.Unlock()                                  // release the mutex
    runtime_notifyListWait(&c.notify, t)          // suspend goroutine
    c.L.Lock()                                    // re-acquire lock on wake
}

Key Takeaways:

There’s a checker to prevent copying the Cond instance, it would be panic if you do so -> anyway, we don't care abt it's detail
Calling cond.Wait() immediately unlocks the mutex -> mutex must be locked before we call cond.Wait()
After being notified, this method will lock the mutex again -> you need to unlock it after you done with shared data

Signal vs Broadcast

Method	Meaning
`Signal()`	Wakes up 1 goroutine
`Broadcast()`	Wakes up all waiting goroutines

Conclusion

Polling based flow:

┌──────────────┐       ┌────────────────────┐
│  Goroutine A │────→  │ tryGetConnection() │
└──────────────┘       └────────────────────┘
       │                         │
       ▼                         ▼
  [Not Available]         →   Sleep(100ms)
       │                         │
       └───── loop ──────────────┘

Fan keeps knocking: “DJ, can I dance now? … How about now? … Still no?”

Loop repeats wastefully
Sleep is either too short (CPU burn) or too long (latency)

`sync.Cond` Flow (Efficient + Coordinated)

                   [ DJ thread ]
┌──────────────┐     time.Sleep
│ Goroutine B  │────────────────────┐
└──────────────┘                    │
        │                           ▼
        │                    ┌──────────────┐
        │                    │  showReady = true
        │                    │  cond.Signal()
        │                    └──────┬───────┘
        ▼                           │
┌────────────────────────────────┐  ▼
│   Goroutine A (waiting fan)    │◄─┘
│  mu.Lock()                     │
│  while !showReady {           ◄──────────────┐
│      cond.Wait() (sleep)                  │
│  }                                        │
│  // Proceed to dance 💃                   │
└────────────────────────────────┘

Fan enters the club, sits quietly. DJ announces:

“🎧 The beat drops!”

Fan wakes up instantly:

“💃 I’m dancing!”

Sleeps peacefully while waiting

Wakes up only when ready

CPU usage remains near-zero

Wrap-up

Don’t burn out your CPU (or your DJ). If you’re managing shared resources in Go and you’re still writing polling loops, it’s time to level up with sync.Cond.
This pattern:

Scales beautifully
Imprves latency
Gives you precise coordination

When Should You Reach for `sync.Cond`?

Use it when

You have a shared condition
And multiple goroutines wait on it
And that condition is protected by a mutex
And polling is not acceptable Don’t use it if:
A simple chan will do
You don’t already hold a mutex around the state

Bonus: real-world use case: connection pool

The Problem With Polling:

Time a go I already have a nice tcp server implementation setup in golang.
To implement this kind of custom tcp server, we need st called connection pool for maximize the power of machines, allow more concurrency operation.

So the first implementation look like this: bad pattern (but a common one):

for {
    if conn := tryGetConnection(); conn != nil {
        return conn
    }
    time.Sleep(100 * time.Millisecond) // 👎 try polling
}

What happened next?

CPU burned — even when no connection was available
Latency grew — increase sleep = slower reaction, decrease sleep = higher CPU
1,000 goroutines polling = chaos
Edge cases everywhere — race conditions like being woken just before state changed

Thanks to sync.Cond which perfectly resolve this problem:

cond.L.Lock()
for !hasFreeConnection() {
    cond.Wait()
}
conn := acquireConnection()
cond.L.Unlock()
return conn

What changed?

No more busy loops
CPU usage drops to near zero while waiting
Only woken when it matters
No weird races or wasted wakeups

Someone will ask me st like this:

Why not use channels instead?

Well, to be honest, my 2nd try consider buffered channel of net.Conn and it can resolve the problem.

and that works… until it doesn't.

Channels are great for linear producers/consumers
But don’t scale well to:
- broadcast wakeups
- shared state protected by mutex
- non-linear wake patterns Channels are data pipes. sync.Cond is a condition watcher.

Think of channels as a delivery guy.

Think of sync.Cond as a waiter with a bell: “Your table is ready!”

You have a []*ConnWrapper, and you want to hand out a free one. If none are free, you wait — but you don’t burn the CPU.

for {
    pool.Lock()
    for !hasFreeConn(pool.connections) {
        pool.cond.Wait()
    }
    conn := grabFreeConn()
    pool.Unlock()
    return conn
}

When a connection is returned:

pool.Lock()
markConnFree(conn)
pool.cond.Signal()
pool.Unlock()

You could be scaling up to thousands of goroutines, and CPU usage would still be flatlined at.

Here's the full implementation

type ConnWrapper struct {
    conn  net.Conn
    inUse bool
}

type ConnectionPool struct {
    connections []*ConnWrapper
    mu          sync.Mutex
    cond        *sync.Cond
}

func NewConnectionPool(size int) *ConnectionPool {
    pool := &ConnectionPool{}
    pool.cond = sync.NewCond(&pool.mu)

    // Initialize dummy connections (you can replace with real dials)
    for i := 0; i < size; i++ {
        pool.connections = append(pool.connections, &ConnWrapper{conn: nil, inUse: false})
    }

    return pool
}

func (p *ConnectionPool) hasFreeConnection() bool {
    for _, cw := range p.connections {
        if !cw.inUse {
            return true
        }
    }
    return false
}

func (p *ConnectionPool) acquireConnection() net.Conn {
    for _, cw := range p.connections {
        if !cw.inUse {
            cw.inUse = true
            return cw.conn
        }
    }
    return nil
}

// GetConnection blocks until one is available
func (p *ConnectionPool) GetConnection(ctx context.Context) (net.Conn, error) {
    p.mu.Lock()
    defer p.mu.Unlock()

    for !p.hasFreeConnection() {
        waitCh := make(chan struct{})
        go func() {
            p.cond.Wait()
            close(waitCh)
        }()

        select {
        case <-ctx.Done():
            return nil, ctx.Err()
        case <-waitCh:
            // recheck in next loop
        }
    }

    conn := p.acquireConnection()
    return conn, nil
}

func (p *ConnectionPool) ReleaseConnection(conn net.Conn) {
    p.mu.Lock()
    defer p.mu.Unlock()

    for _, cw := range p.connections {
        if cw.conn == conn {
            cw.inUse = false
            break
        }
    }

    p.cond.Signal() // Wake up one goroutine waiting
}

References

Go Official Documentation – sync.Cond https://pkg.go.dev/sync#Cond The authoritative source explaining how Cond works and how to use it properly.
Go Blog – Share Memory by Communicating https://go.dev/blog/share-memory-by-communicating Go’s philosophy on concurrency. Although sync.Cond is a shared-memory primitive, this blog explains when it’s okay to step outside channels.
"Practical Go Concurrency Patterns" – Google I/O talk https://www.youtube.com/watch?v=QDDwwePbDtw Great visual explanation of channels, mutexes, sync.Cond, and when to use what.
Go Forum: Why sync.Cond Over Channels https://forum.golangbridge.org/t/what-is-the-difference-between-channel-and-sync-cond/13125 A useful community thread with insights into differences, tradeoffs, and when Cond is a better fit than channels.
Source code for sync.Cond.Wait() (Go standard library) https://github.com/golang/go/blob/master/src/sync/cond.go For those who want to go under the hood and see how Wait() really works internally (with runtime_notifyListWait).
Advanced Go Concurrency Patterns – Francesc Campoy https://www.youtube.com/watch?v=QDDwwePbDtw Covers deep concurrency primitives including real-world use cases of sync.Cond.

[GCP] Resource vs Billing management

Nguyễn Long — Sun, 06 Oct 2024 16:11:02 +0000

Resource hirarchy

5 levels:

Domain
Organiztion
Folders
Projects
Resources

To create resource, must create project level first
1 resource could be in only one project
Not be able to be in multiple projects at the same time.

Resources

Including Service resource of gg cloud example: VMs, Storage....etc

Labels:

Help categorize resources by key value pair

Billing Account:

Role:

Billing account creator
- Permissions: Can create new billing accounts.
- Use Case: Typically assigned to individuals responsible for setting up billing for a project or organization.
Billing account user
- Permissions: Allows a user to associate projects with a billing account and view basic billing information.
- Use Case: Useful for team members who need to link projects to the billing account but don’t require full management permissions.
Billing Account Viewer
- Permissions: Can view billing information, such as reports and transaction details, but cannot make changes or associate projects with billing accounts.
- Use Case: Best for stakeholders who need visibility into billing without the ability to modify settings (e.g., financial auditors).
Project Billing Manager
- Permissions: Can link or unlink billing accounts to/from specific projects but cannot view billing details or manage the billing account itself.
- Use Case: Ideal for project managers who need control over which billing account is linked to their projects but do not need access to overall billing data.
Billing account Administrator:
- Permissions: Has full control over the billing account, including managing payment methods, viewing reports, associating projects, and assigning roles.
- Use Case: Best suited for individuals or teams responsible for overseeing all billing-related activities for an organization.

Cost Management and Budget Alerts

Commited Use Discounts (CUD's)

Discount prices when you commit to using a minimum level of resources for a specified term

1 or 3 years commitment
2 types commitment

Spend based
Resource based

Spend based commitment

Discount for a commitment to spend a minimum amount for a service (hours) in a particular region

If you commit to spending $100,000 on Compute Engine over a one-year period, Google Cloud may offer you a discounted rate on that service. You can use the Compute Engine resources freely within that spend, benefiting from the lower costs.

Spend-based commitments are ideal for organizations with predictable cloud usage that want to optimize their costs while maintaining flexibility.

If you do not use the entire $100,000 commitment over the one-year period?

you will still be required to pay the full committed amount. Spend-based commitments in Google Cloud are binding, meaning that you are obligated to pay for the amount you committed to, even if your actual usage falls short of that amount.

Full Payment Obligation: You will still be charged the full $100,000, regardless of your actual consumption.
No Refunds: Google Cloud does not refund or reduce your payment if you do not fully utilize the committed spend.
Planning Considerations: To avoid this, it’s essential to carefully estimate your anticipated cloud usage before entering into a spend-based commitment.

What Happens If You Use More Than $100,000 ?

If you use more than the committed amount (in this case, over $100,000) during the one-year period, the excess usage will be billed at the standard pay-as-you-go rates without any additional discounts from the spend-based commitment.

Discount Applies Only Up to the Committed Amount: You receive discounted pricing only for the committed $100,000. Once you exceed this amount, any further usage is charged at the regular on-demand rates.
No Penalties for Over-Usage: You are free to use more than your commitment, but the discounts do not apply beyond the committed spend.
Regular Billing for Excess Usage: Any usage beyond your commitment will be billed monthly, just like regular Google Cloud billing, but without the discounted rates.

Benefit?

25% discount for 1 year - 52% discount for 3 year

Available for :

Cloud SQL instacnes:
BigQuery Reservations
GG VMWare Engine:
- Google Kubernetes Engine (GKE)
- Google Cloud Compute Engine
- Cloud Run

Applies only to CPU and memory usage

Resource based commitment

Discount for a commitment to spend a minimum amount for compute Engine resources in a particular region

For example, you might commit to using 64 vCPUs and 256 GB of memory for a one-year term.

Available for :

vCPU, Memory, GPU and Local SSD

Discounted Pricing: In exchange for committing to these resources, you receive a substantial discount (often up to 50-70% off) compared to the regular, on-demand rates.

57% discount for most resource
70% for memory-optimized machine types

For use across Projects

Use case:

Predictable Workloads: This option is ideal for workloads that are predictable and steady, as it helps reduce costs significantly over time.
Applicable to Specific Services: Resource-based commitments are most commonly used for:
- Compute Engine: Virtual machine (VM) instances, CPU, RAM, GPUs.
- Google Kubernetes Engine (GKE): Resources used by Kubernetes - clusters.
- Cloud SQL: For database resource allocations (vCPUs and RAM).
- Cloud Spanner: For specific database instances and resources. ### Example: If you commit to using 100 vCPUs and 512 GB of RAM for a one-year period for Compute Engine, you’ll receive a discounted price for this specific resource allocation. If you use more than this, the additional resources will be charged at the regular rate, but if you use less, you’ll still be charged for the committed resources. ## Sustained-use discounts Automatic discounts for running Compute Engine resources a significant portion of the billing month Applies to vCPUs and memory for most Compute Engine instance types

Does not apply for App Engine flexible:

Dataflow
E2 machine types

Key Feature

Automatic Discounts:
- SUDs are automatically applied when you use a Compute Engine VM for more than 25% of a month. The longer you run the VM, the larger the discount becomes, reaching up to 30% off the standard price when the VM is used for nearly the entire month.
No Commitment Required:
- Unlike committed-use contracts, there’s no need to pre-purchase or commit to a specific amount of resources. The discount is automatically applied based on how long you use the VM each month.
Proportional Discounts:
- The discount grows as your usage increases. Here’s a breakdown:
  - For the first 25% of the month, you pay the full price.
  - For 25% to 50% usage, you get a small discount.
  - For 50% to 75% usage, the discount increases further.
  - For usage above 75%, you get the maximum discount (up to 30%).

Cloud Billing Budgets

Enable you to track your actual Google Cloud spend against your planned spend

Budget alert threshold rules that are used to trigger email notifications to help you stay informed about your spend

Feature:

Define the scope of the budget

Spen of billing account or more granular

Budget amount can be set to a specified total, or based on previous month's spend

Alert emails are sent to billing account admins and specific users when costs exceed a percentage of the budget

Handling Transactions Without Breaking Service-Adapter Decoupling in Hexagonal Architecture with Golang

Nguyễn Long — Tue, 01 Oct 2024 00:17:31 +0000

Handling Transactions Without Breaking Service-Adapter Decoupling in Hexagonal Architecture with Golang

Introduction

When building applications in Go using hexagonal architecture (also known as Ports and Adapters), maintaining a clear separation between the service layer and the adapter layer is essential.

One challenge that developers often face is managing database transactions within this architecture without violating service-adapter decoupling.
I will walk you through a common problem of transaction handling and how to refactor your Go code to solve it.

Problem: Transactions and Decoupling

In hexagonal architecture, the service (business logic) should not be aware of infrastructure details such as transaction management.
The service layer should focus purely on business rules and defer infrastructure operations like database interactions to the adapter layer.
Transaction handling, like db.Begin(), often ends up being tightly coupled to the service layer, leading to design that violates the principle of separation.

Consider the following example, where transaction logic leaks into the service layer:

// UserService (Service Layer)
type UserService struct {
    userRepo port.UserRepo
    logRepo  port.LogRepo
}

func (u *UserService) CreateUser(ctx context.Context, user domain.User) error {
    // Transaction begins in the adapter
    tx := u.userRepo.BeginTransaction(ctx)

    // Create user
    createdUser, err := u.userRepo.CreateUser(ctx, user)
    if err != nil {
        tx.Rollback()
        return err
    }

    // Create task for the user
    task, err := u.userRepo.CreateTask(ctx, createdUser)
    if err != nil {
        tx.Rollback()
        return err
    }

    // Log the task
    err = u.logRepo.LogTask(ctx, task)
    if err != nil {
        tx.Rollback()
        return err
    }

    // Commit transaction if all steps succeed
    return tx.Commit()
}

This example is a basic operation for for User and Task Management System. Here is the break down:

First, user will be created
After user created, some Task instances will create for that user
After task creation, the system will log the task for the user.

At this point we may noticed that if any of this task fail, then it should be rollback, otherwise, the actions will be commited.

But, What's Wrong with This Approach?

At first glance while this might seem functional, the CreateUser method in the service layer is managing the transaction (BeginTransaction, Rollback, Commit), which should be the responsibility of the adapter layer.
Handling transactions directly in the service? -> violate the decoupling principle. -> harder to maintain and scale your code, as the service layer now knows too much about the infrastructure

A Better Solution: Apply Unit of work pattern

The Unit of Work pattern groups multiple operations into a single transaction and ensures that all changes are committed or rolled back as a unit. The Unit of Work itself can manage the transaction across repositories. It acts as a coordinator for all database changes that happen during a business operation.

type UnitOfWork struct {
    db *sql.DB
}

func (uow *UnitOfWork) Begin(ctx context.Context) (context.Context, error) {
    tx, err := uow.db.Begin()
    if err != nil {
        return ctx, err
    }
    uow.tx = tx
    return context.WithValue(ctx, TransactionKey, tx), nil
}

func (uow *UnitOfWork) Commit() error {
    return uow.tx.Commit()
}

func (uow *UnitOfWork) Rollback() error {
    return uow.tx.Rollback()
}

In this case, the UnitOfWork is passed around to each repository, ensuring all operations within a transaction are coordinated. The service layer simply calls the Unit of Work to start and complete transactions.

UserService now will be:

func (u *UserService) CreateUser(ctx context.Context, user domain.User) error {
    uow := UnitOfWork{}
    ctx, err := uow.Begin(ctx, u.db)
    if err != nil {
        return err
    }

    createdUser, err := u.userRepo.CreateUser(ctx, user)
    if err != nil {
        uow.Rollback()
        return err
    }

    task, err := u.userRepo.CreateTask(ctx, createdUser)
    if err != nil {
        uow.Rollback()
        return err
    }

    err = u.logRepo.LogTask(ctx, task)
    if err != nil {
        uow.Rollback()
        return err
    }

    return uow.Commit()
}

Repo Layer: It will get the transaction from the context:

// UserRepoImpl (Adapter Layer)
type UserRepoImpl struct {
    db *sql.DB
}

func (u *UserRepoImpl) CreateUser(ctx context.Context, user domain.User) (domain.User, error) {
    // Use the transaction from context
    tx := ctx.Value(TransactionKey).(*sql.Tx)
    // Execute user creation within the transaction
    result, err := tx.Exec("INSERT INTO users ...")
    if err != nil {
        return domain.User{}, err
    }
    // Logic to create and return the new user
    return createdUser, nil
}

func (u *UserRepoImpl) CreateTask(ctx context.Context, user domain.User) (domain.Task, error) {
    tx := ctx.Value(TransactionKey).(*sql.Tx)
    // Execute task creation within the transaction
    result, err := tx.Exec("INSERT INTO tasks ...")
    if err != nil {
        return domain.Task{}, err
    }
    return task, nil
}

By making use of callback and pass transaction via context, We can get the benefits:

Service layer no longer handles transaction management. It simply focuses on business logic.
All transaction-related concerns are handled in the repository (adapter) layer, making it easier to change or extend the infrastructure layer without affecting the service.
The Unit Of Work method can be reused across different service methods that require transaction handling, reducing code duplication.
Easier to test because it’s not tied to the database context.

Conclusion

Decoupling transaction management from the service layer and moving it to the adapter layer helps you adhere to the principles of hexagonal architecture. This refactor not only keeps the layers clean and independent but also improves the maintainability and scalability of your application. In Golang, this approach can be easily implemented using contexts to pass transactions and callback functions to execute business logic within the transaction scope.

Ref:

GCP compute options

Nguyễn Long — Mon, 30 Sep 2024 22:18:19 +0000

Introduction
Deep Dive into GCP Compute Options
1. Google Compute Engine (GCE) – Virtual Machines
  - Features
  - Use Cases
2. Google Kubernetes Engine (GKE) – Container Orchestration
  - Features
  - Use Cases
3. App Engine – Platform-as-a-Service (PaaS)
  - Features
4. Cloud Functions
  - Features
  - Use Cases
Comparison Table

Introduction:

💡 So, you’re building something cool on GCP, and now you need to pick the right compute option. It's like standing in front of a vending machine of cloud services: “Do I want a classic virtual machine? Or should I get some fancy containers? Maybe I'll go serverless and just have it magically work.”

In Google Cloud Platform, you’ve got choices—and lots of them. But don’t worry, it’s not as confusing as picking the perfect avocado. Let’s break it down, step by step, with a little fun along the way. Think of each compute option like different modes of transportation:

💻 Virtual Machines (VMs): You’re driving your own car. Full control, but hey, you’ve got to maintain it
☸️/🐳 Containers (GKE/Cloud Run): Hop on a public bus. You are sharing, but it's efficent and flexible.
🌍 Serverless (App Engine/Cloud Funcion): Teleportation... You dont know how, but you're there when you need to be.

Deep Dive into GCP Compute Options

1. Google Compute Engine (GCE) – Virtual Machines

VMs💻 are called instance andd need to choose region and zone to deploy.
You choose the OS and specify the application you put on it.

GCE provides traditional virtual machines that give you complete control over the operating system and infrastructure. You manage everything: scaling, patching, and maintaining the VMs. This is ideal for legacy applications, specialized workloads that need specific OS configurations, or high-compute tasks that demand fine-grained control.

Features:

Full control over OS
Custom VM type ot predefined ones
Suitable for workloads that require specific lib or frameworks
Manging multiple instances using instance groups
Add/remove capacity using autoscaling with instance groups
Attach/detach disks as needed.
Can SSH directly

Use Cases:

Hosting legacy applications that aren’t easily containerized.
Running high-performance computing (HPC) tasks or workloads that need fine-tuning
Applications that require stateful operations

Let’s say you’re running a finance application that needs specific security patches and configurations to meet regulatory compliance. VMs are perfect because you control every layer, including the OS.

2. ☸ Google Kubernetes Engine (GKE) – Container Orchestration

Is container-oschestration system for automating deploying,scaling and managing containers
Built in* open-source Kubernetes*
Flexibility to inegrate with on-premise Kubernetes.
Uses compute engine instances as nodes in a clusters ☸
Cluster is group of nodes or compute engine instances.

Features:

Automatic scaling and self-healing containers.
Runs across multiple zones for redundancy.
Integrates with Google’s stack, like Cloud Monitoring and Logging.

Use Cases:

Running microservices architectures, where each service can scale independently.
Applications that need high availability across zones.
Workloads requiring container orchestration with easy management.

🧠 Think of an ecommerce app that needs independent scaling for different services (checkout, inventory, recommendations). With GKE, you deploy each service in a container, ensuring that traffic spikes on one service don’t affect the others.

3.🚀 App Engine – Platform-as-a-Service (PaaS)

Fuly managed, serverless platform for developing and hosting web applications at scale (PaaS)

Features:

Provisions servers and scales your app instances based on demand
Build your app by favourite lanaguage
Connect with GG services seamlessly like Firestore, Cloud SQL, and Pub/Sub.
Integrates with Web sec scanner to identify threats.

👉 App Engine is a fully managed platform that abstracts away infrastructure management. You focus on writing your code while App Engine handles everything from scaling to monitoring. It’s great for developers who want to focus on code, not infrastructure.

4. Cloud Function (λ)

Serverless Execution env for building & connecting cloud service

Features:

Simple, single-purpose functions that are attached to events
Triggerd when an event being watched is fired
Your code executes in a fully managed env
No need to provision any infrastructure
Event-driven: Automatically executes in response to triggers.
Scales automatically with traffic.
Perfect for lightweight, short-duration tasks.

Use case:

ETC
hook
APIs
Mobile backend functions
FaaS

Comparison Table:

Service	Type	Management Level	Scaling	Cost Model	Best For
Compute Engine	VMs	Full control	Manual or autoscaling	Pay for uptime	Legacy apps, specialized OS control
Kubernetes Engine (GKE)	Container orchestration	Managed	Automatic, multi-zone availability	Pay for instance uptime	Microservices, high availability
Cloud Run	Serverless containers	Fully managed	Scales to zero	Pay per request	Stateless apps, event-driven microservices
App Engine	PaaS	Fully managed	Automatic, scales based on traffic	Pay per instance uptime	Web apps, mobile backends
Cloud Functions	Serverless functions	Fully managed	Automatic, scales to zero	Pay per execution	Event-driven, lightweight tasks

GCP Global Infrastructure

Nguyễn Long — Mon, 30 Sep 2024 21:36:47 +0000

Google Cloud had been designed to serve all users worldwide by designing the infrastructure with redundant regions connected with high bandwidth connecting different continents.
Invested 13 Subsea Cables Connecting these continents(100,000 miles of fiber cable)

24 Regions
73 Zone
144 Network edges location
200+ countries and territory

In cloud computing, the terms zone, region, and multi-region are used to describe the geographical organization of cloud resources, which impacts performance, availability, and redundancy.

Zone:

A zone is a specific, isolated data center within a region. Each region contains multiple zones (usually 3 or more). Zones are independent of one another to ensure high availability.
Resources (like VMs, databases) within a zone can communicate with very low latency.
If a zone goes down (due to a failure or maintenance), other zones in the same region continue to operate.

Key Points:
- Zone = Individual data center within a region.
- Isolated: Redundant setup ensures high availability.
- Low latency communication between resources in the same zone.

Region:

A region is a geographical location that contains multiple zones (typically 3 or more). For example, us-central1 is a region.
A region ensures redundancy by spreading resources across multiple zones, reducing the risk of downtime due to failures in one zone.
Each region is designed to be independent of other regions to ensure fault tolerance and minimize latency for users in that geographical area.

Key Points:
- Region = Group of zones in a specific geographical area.
- Ensures redundancy and low latency for local traffic.
- Independent of other regions for fault tolerance.

Multi-region:

Multi-region refers to deploying resources across multiple regions. This approach is used to improve disaster recovery, global availability, and latency reduction for users in different parts of the world.
Services that need global reach or highly available systems may use multi-region setups to ensure that even if one region goes down, others can take over without downtime.
Examples include Google Cloud Storage or databases set up in a multi-region configuration.

Key Points:
- Multi-region = Resources spread across several regions.
- Improves global availability and disaster recovery.
- Reduces latency for users in different geographical areas.

DEV Community: Nguyễn Long

From Polling to Partying: Writing Cooler Goroutines with sync.Cond

TL;DR

So, What is sync.Cond?

You use it when:

Business Analogy

Now let's talk about the correct way to use this mechanism:

Why not just time.Sleep()?

How Does Wait() Actually Work?

Here’s the implementation under the hood:

Key Takeaways:

Signal vs Broadcast

Conclusion

Polling based flow:

sync.Cond Flow (Efficient + Coordinated)

Wrap-up

When Should You Reach for sync.Cond?

Bonus: real-world use case: connection pool

The Problem With Polling:

What changed?

Why not use channels instead?

and that works… until it doesn't.

References

[GCP] Resource vs Billing management

Resource hirarchy

Resources

Billing Account:

Cost Management and Budget Alerts

Commited Use Discounts (CUD's)

Spend based commitment

If you do not use the entire $100,000 commitment over the one-year period?

What Happens If You Use More Than $100,000 ?

Benefit?

Resource based commitment

Use case:

Key Feature

Cloud Billing Budgets

Feature:

Handling Transactions Without Breaking Service-Adapter Decoupling in Hexagonal Architecture with Golang

Handling Transactions Without Breaking Service-Adapter Decoupling in Hexagonal Architecture with Golang

Introduction

Problem: Transactions and Decoupling

But, What's Wrong with This Approach?

A Better Solution: Apply Unit of work pattern

Conclusion

GCP compute options

Table of Contents

Introduction:

Deep Dive into GCP Compute Options

1. Google Compute Engine (GCE) – Virtual Machines

Features:

Use Cases:

2. ☸ Google Kubernetes Engine (GKE) – Container Orchestration

Features:

Use Cases:

3.🚀 App Engine – Platform-as-a-Service (PaaS)

Features:

4. Cloud Function (λ)

Features:

Use case:

Comparison Table:

GCP Global Infrastructure

Zone:

Region:

Multi-region:

So, What is `sync.Cond`?

Why not just `time.Sleep()`?

How Does `Wait()` Actually Work?

`sync.Cond` Flow (Efficient + Coordinated)

When Should You Reach for `sync.Cond`?