DEV Community: Andrew David

How to Implement In-Memory Caching in GoLang

Andrew David — Thu, 27 Nov 2025 13:18:15 +0000

The Why?

I recently worked on Airtable OAuth authentication for a project and needed a place to store state and challenge code for later request validation. The obvious solution is to use a third-party solution like Redis (Which I am a big fan of), but I wanted to try out in-memory caching. Yes, I reviewed other tools like MemeCache, but am I not an engineer?

The What?

When you start your Go app, Python app, or Node app, you can store certain data in the process, making it available throughout the program's lifetime. This data lives in the RAM (Random Access Memory), making it easily accessible by the program whenever it needs it. Most caching systems like Redis also store their data in RAM, but unlike Redis, an in-memory cache is not persistent.

A simple in-memory cache typically maintains a key-value store in memory, tracks when each item should expire (using TTL — Time to Live), and optionally uses an LRU (Least Recently Used) policy to remove older items when a maximum size is reached. The cache runs in the same process as your application, making reads and writes extremely fast. However, because everything is stored in memory, all data is lost when the application stops.

Less Talk, more code !!!

Before we code, let’s go over a few things I think you should know

LRU (Least Recently Used) → My phone has a bunch of apps that I do not use—apps that have been on my phone for the longest time, occupying good space. LRU is an eviction policy that removes the least-used item in a cache. Essentially, think of it as removing that app you haven’t used in months so you can make room for the new game you want to install. Essentially, you are removing the oldest unused item, regardless of whether it has been accessed a lot in the past.
LFU (Least Frequently Used) → Imagine this: your bag can only hold four books. If you get a new one, you'll need to remove a book to make room, and usually, you'll remove the book you read less. The same thing applies to an in-memory cache. LFU is an eviction policy that ranks items based on how often they’re used, and when space runs out, it removes the least-frequently-used item to make room for new ones.
TTL (Time To Live) → This defines how long we want an item to stay in our cache. It's like setting an expiry date — once the TTL has elapsed, the item is considered stale and no longer valid. Any future attempts to get that item will fail or trigger a refresh. TTL is useful for keeping data fresh and automatically clearing out old or irrelevant entries without needing manual intervention or cleanup.
Cache Hit, Cache Miss → Whenever we request an item from the cache, a cache hit occurs if the item exists and is still valid. A cache miss, on the other hand, happens when the item is not found or has expired.

So now we code, right?

Well, not just yet, there are still a few things we need to talk about, sorry :)

The Design

To build our cache, we’re going to keep things simple with just three components:

A map to store the items
The cache itself
A Janitor to clean up our mess

Now we code

Let’s start by defining a very simple struct to hold all the data. After that, I’ll walk you through what each part represents.

// Cache Items
type Item struct {
    value    interface{}
    duration int64
}

// Main cache struct
type cache struct {
    items   map[string]Item
    mu      sync.RWMutex
    janitor *Janitor
}

// handles clean up
type Janitor struct {
    interval time.Duration
    stop     chan bool
}

The Item struct contains two fields: Value and Duration. Normally, you might use time.Time for expiration, but here, Duration is stored as an integer timestamp—a design choice to keep things simple and flexible.

As for the Cache struct, you might notice that it's unexported (made private). This allows us to expose a global constructor to create the cache instance. The real reason behind this design, though, is that I implemented it using the singleton pattern—meaning I wanted to ensure that only one instance of the cache exists throughout the entire program.

One thing I may have forgotten to mention is that our cache needs to be thread-safe. This means it should prevent race conditions, where two processes or goroutines try to modify the state of the cache at the same time.

Go provides a solution for this through the use of a mutex—a locking mechanism that ensures only one thread or goroutine can access a resource at a time. By locking the cache during operations, we prevent data corruption and maintain consistency.

Another important component is the Janitor. This is a lightweight scheduler that periodically runs in the background to clean up expired items from the cache. It helps free up memory and makes room for newer items, keeping the cache lean and efficient.

Expanding Item

//Check if Item is expired
func (this Item) Expired() bool {
    if this.duration == 0 {
        return false
    }
    return time.Now().UnixNano() > this.duration
}

This method returns a bool indicating whether an item has expired by checking if its timestamp (Duration, remember) is less than the current time. But before doing that, it first checks if the Duration is 0. If it is, the method returns false, meaning the item should not expire.

This is intentional. Sometimes, you may not want certain items in the cache to ever expire—you want them to persist for as long as the program is running. In this design, any item with a Duration value of 0 is treated as having no expiration, and therefore is never evicted by the cleanup process.

Set

Now we can begin working on our cache. The first method we’re going to add is Set—this allows us to populate the cache with data that we can retrieve and use later.

// Store a value in cache with a defined ttl
func (c *cache) Set(key string, value interface{}, ttl time.Duration) {
    defer c.mu.RUnLock()
    var d int64
    if ttl == 0 {
        ttl = DefaultDuration
    }
    if ttl > 0 {
        d = time.Now().Add(ttl).UnixNano()
    }
    c.mu.RLock()
    c.items[key] = Item{
        value:    value,
        duration: d,
    }
    return
}

The Set method stores a value in the cache under a specific key, along with an optional TTL (Time To Live). If no TTL is provided, and the DefaultDuration is 0, the item will be stored without expiration, meaning it will stay in the cache indefinitely unless manually removed.

If a TTL is provided (i.e. greater than zero), it is converted to a Unix timestamp (int64) for efficient comparison during retrieval or cleanup.

Finally, the method locks the cache for writing to ensure thread safety, then inserts the item into the cache map.

Let’s do Get, Delete, Len, you get the gist now

// Get an Item from store using its key
func (c *cache) Get(key string) (interface{}, bool) {
    c.mu.RLock()
    item, ok := c.items[key]
    if !ok {
        return nil, false
    }
    if item.Expired() {
        c.mu.RUnlock()
        return nil, false
    }
    c.mu.RUnlock()
    return item.value, true
}

// Delete an item from store by its key
func (c *cache) Delete(key string) bool {
    c.mu.RLock()
    if _, ok := c.items[key]; !ok {
        return false
    }
    delete(c.items, key)
    c.mu.RUnlock()
    return true
}

// Return the lenght of items in store
func (c *cache) Len() int {
    c.mu.RLock()
    n := len(c.items)
    c.mu.RUnlock()
    return n
}

Alright, we’re almost done—I promise. The Get function retrieves an item from the cache using its key. First, it locks the cache for reading and checks if the key exists in the items map. If it doesn’t, it returns nil and false.

If the item does exist, the function checks whether it has expired using the Expired() method. If it has, it unlocks the cache and returns nil and false. Otherwise, it returns the item’s value along with true to indicate a successful cache hit.

The next function is Delete. This function removes an item from the cache by its key. It first locks the cache for reading and checks if the key exists in the items map. If it doesn’t, it returns false.

If the key exists, it deletes the entry from the map and then unlocks the cache. Finally, it returns true to indicate that the item was successfully removed.

And finally Len. This returns the length of items in the items map; nothing too fancy here.

But wait, there is one more thing

// Delete all expired items from store
func (c *cache) DeleteExpired() {
    c.mu.RLock()
    for k, v := range c.items {
        if v.Expired() {
            c.Delete(k)
        }
    }
    c.mu.RUnlock()
}

Remember when I mentioned we have a Janitor? The DeleteExpired function is part of that cleanup process. It loops over all the items in the store and checks whether each one has expired. If an item is expired, it calls the Delete function to remove it from the cache.

This helps ensure the cache doesn't keep stale data and frees up memory for new entries, keeping the cache clean.

The Janitor

Now let’s talk about how the Janitor runs.

// Run janitor clean up after intervals
func (j *Janitor) Run(c *cache) {
    ticker := time.NewTicker(j.interval)
    for {
        select {
        case <-ticker.C:
            c.DeleteExpired()
        case <-j.stop:
            ticker.Stop()
        }
    }
}

The Run method starts a ticker that fires at intervals defined by the user. On each tick, it calls DeleteExpired() on the cache — this is how we automatically clean up expired items without the user needing to call anything manually.

We also listen for a stop signal through the stop channel. Once that signal is received, we stop the ticker and exit the loop.

func stopExceution(c *cache) {
    c.janitor.stop <- true

}

func startJanitor(interval time.Duration, c *cache) {
    janitor := &Janitor{
        interval: interval,
        stop:     make(chan bool),
    }
    c.janitor = janitor
    go janitor.Run(c)
}

There’s also a stopExecution function that sends the stop signal to the janitor. This gives us a way to gracefully shut down the cleanup process when the program is closing or we no longer need the cache.

Finally, the runJanitor function wires everything together. It creates a new Janitor with a cleanup interval, assigns it to the cache, and runs it in a goroutine so it works in the background.

Putting it all together

func GetCache() *cache {
    items := make(map[string]Item)
    once.Do(func() {
        defaultCache = &cache{
            items: items,
        }
        runJanitor(DefaultCacheInterval, defaultCache)
        runtime.SetFinalizer(defaultCache, stopExceution)
    })
    return defaultCache
}

Now we can run our cache and see our little in-memory cache in action

Conclusion

This is a very small and maybe not production-ready cache, but I still remember the excitement I felt when it finally worked—and how it helped me with my little project (which I promise I did not abandon).

In my next article, we’ll look at how to expand this further by adding LRU support to the cache.

Now remember: just because you can build something yourself doesn’t always mean you should. It’s often a smart move to use existing tools, especially when caching isn’t the core of your project.

That said... I do think you should try building your own multi-auth system at least once. Until next time ✌🏽

x402: Pay-Per-Use Internet

Andrew David — Thu, 27 Nov 2025 13:07:09 +0000

We All Hate Free Trials (Well, I Do)

Sometimes I just want to test something new. Maybe it’s a new AI image tool, a premium API, pay for a digital content to a creator, some data service everyone won’t shut up about. But nope—the first thing I see is “Start your 7-day free trial!” Great… except now I have to hand over my card on day one. Then I spend the whole week stressing that I’ll forget to cancel and get slapped with a $99 charge for something I used only once.

Even worse: sometimes I want my AI agent (ChatGPT, Claude, Grok) to use that service for me. Which means what—give my card to the AI? I’m reckless, but an AI agent is probably ten times more reckless than me.

It’s dumb. We shouldn’t need credit cards just to test stuff. With x402, I load a single wallet once—with however much I feel like (even five bucks). From that moment on, me and any AI agent I control can tap into hundreds of services and pay only for what we actually use, down to the penny. No cards floating around. No surprise bills. No “don’t forget to cancel” alarms. I pay for what I use. My agent pays for what it uses. Everyone wins.

So what is x402 and Why?

The Evolution of Web Payments — and Why x402 Matters

The 402 status code has been around since the very beginning of HTTP. The idea was simple: if a resource needs payment before you can access it, the server would return a 402.

The problem: nobody actually used it.

Not because the idea was bad, but because there was no standard way to pay over HTTP. So developers defaulted to 403 Unauthorized, and everyone just built their own systems—subscriptions, one-time links, prepaid credits.

These solutions work, but they all live outside the actual web request. The big unanswered questions were:

How do we handle payments inside a request?
How do we send payments over HTTP?

Stablecoins Changed the Game

Then stablecoins blew up. Between 2021 and 2025:

Supply jumped from under $30B to over $280B
On-chain volume hit $27 trillion
Governments finally gave clear rules (EU’s MiCA, U.S. GENIUS Act, and similar laws)

Stablecoins basically became the first form of money that’s fast, global, cheap, programmable, and actually works online. Perfect for internet payments.

x402: Payments Directly Through HTTP

In May 2025, Coinbase introduced x402, a simple idea that unlocks a lot of possibilities. It revives the old 402 status code and gives it a real purpose.

With x402, if a resource requires payment, the server can return a 402 Payment Required response that includes:

how much you need to pay
where to send the payment
optional details about what you're buying

The client—your browser, app, or even an AI agent—can then pay instantly on chains like Solana, Base, or Polygon, and the server delivers the requested content in the same connection. No accounts, no signups Just pay-and-go.

Perfect Timing for AI Agents

AI agents are exploding in popularity, and they constantly make requests, pull data, call APIs, and use computational resources. With x402:

Agents can pay for exactly what they use
MCP servers can charge per request automatically
Digital systems can trade with each other without any human setup

This allows for more robust agentic systems and true agentic commerce

Microtransactions Finally Make Sense

One of the best things about x402 is that tiny payments—stuff like a few cents or even fractions of a cent—actually become practical. With credit cards, fees make this impossible. But with fast crypto networks:

Pay 1¢ to read an article
Pay per API call
Pay by the second for compute
Pay per kilobyte of data

This means companies can finally drop the free trial and allow test the product without having to worry about remembering to cancel another subscription.

So how does It work?

At its core, x402 involves three main players:

The Seller – the server or service hosting the resource you want
The Buyer – you (or your app, agent, or browser)
The Facilitator – the service that verifies signatures and settles payments on-chain

1. The Buyer

You (the buyer) send a regular GET or POST request to the server, but with one extra header:

X-Wallet header, which includes:

your wallet address
the payment methods/networks your client supports

This basically tells the server:

“Hey, I have a wallet. If this costs money, I’m ready.”

2. The Seller

If the resource is paywalled, the server returns a 402 Payment Required response containing an invoice.

Example:

{
  "maxAmountRequired": "0.01",
  "resource": "/api/video/generate",
  "description": "Access requires payment",
  "payTo": "0xABCDEF1234567390ABCDEF1234567890ABCDEF12",
  "asset": "0xA0b86991C6218236c1d19D4a2e9Eb0cE3606EB48",
  "network": "base-mainnet"
}

This tells the buyer exactly what needs to be paid, in what currency, and where.

4. Gasless payments using EIP-3008

x402 uses EIP-3008: TransferWithAuthorization to enable gasless transfers.

Instead of sending a transaction on-chain, the buyer:

Signs a payload authorizing the payment
Sends that signed payload back to the seller in an X-Payment header

Example:

X-Payment: <signed EIP-3008 payload>

No gas. Just a signature.

5. The Seller forwards the signature to the Facilitator

The seller never posts anything directly on-chain.

Instead, it forwards the signed payment to the facilitator, who:

verifies it
settles the payment
confirms everything succeeded

Once payment is settled, the seller returns the requested resource—all in the same request flow.

Why Not API Keys?

x420 shines by allowing users to make transactions without needing API keys or even accounts on the services they interact with. This means a single wallet can grant access to premium services across multiple platforms.

The major advantage is that AI agents can independently compose and pay for API requests without any user intervention. Imagine you have an AI agent that needs to publish posts every day based on what’s trending in the country. Your agent will need:

A search tool to find what’s currently trending
Access to Twitter/X to gather up-to-date news and topics
The ability to publish a post on your Twitter/X account

Normally, this requires API credits and API keys for platforms like Google and Twitter. While manageable for a small project, the number of API keys quickly becomes overwhelming as your system grows and you integrate more services.

With x420, one wallet covers the cost of all transactions, regardless of the number of services involved. All you need to manage is the balance in that single wallet. And you can even set spend limits so your AI agent doese’t spend above a certain threshold.

Now The problem

x402 is impressive—really impressive—but it still carries challenges that are common across the entire crypto ecosystem. The most significant concern is that crypto transactions generally cannot be traced back to a specific individual or organization. While this privacy is a feature, it also creates the potential for x402 to be misused for money laundering or online fraud. These concerns are not unique to x402; they apply broadly to most blockchain-based systems and projects.

Another important issue currently being worked on is transparency. Even though the origin of an agent’s transaction may be private to the service provider, the transaction itself is still publicly visible on the blockchain. This means that, despite appearing anonymous, your agent’s actions can still be tracked, and most users do not want their agent’s financial activity to be publicly exposed.

Addressing this would require privacy-preserving transactions, along with selective disclosure—allowing only authorized parties (such as auditors or regulators) to view transaction details when necessary.

Another concern with x402 is the lack of chargebacks or refunds. Because transactions are irreversible, victims these of scams cannot recover lost funds. This raises the risk of an increase in crypto scams.

One proposed solution is the introduction of reputation systems. Services can be rated by users and agents, and poor ratings reduce the likelihood that others will trust or interact with them. While this improves accountability, it does not fully solve the chargeback problem, as victims still cannot retrieve their money.

The conclusion

So yeah—that’s x402. This article isn’t meant to be highly technical, but it gives you a broad overview of what x402 is and its potential impact on online payments. One user even described it as “the next big thing after sliced bread.”

Innovation around x402 is moving fast, and version 2 is already on the way with even more improvements. One of the most exciting aspects of x402 is that it’s simply a set of rules for moving money over HTTP. Although crypto is currently being used as the payment layer, the standard itself is not limited to crypto. This means x402 has the potential to move even fiat currency over HTTP.

Experiments have already been conducted using services like Stripe—not yet public, but promising—which shows just how far-reaching the potential of x402 could be. The future of online payments built on this standard is genuinely exciting.