Memoization is one of those techniques most Ruby developers start using almost immediately. It's simple, elegant, and often provides significant performance improvements with just a single line of code. Over the years, I've found myself constantly reaching for memoization, but I've also discovered that the common approaches many of us use have a surprising number of edge cases and limitations. That led me to build SafeMemoize, a library designed to make memoization more reliable for real-world applications.

The Problem with Traditional Memoization

Most Ruby developers are familiar with this pattern:

def current_user
  @current_user ||= find_user
end

It's concise and works well most of the time.

Until it doesn't.

If the method returns nil or false, the computation is performed again on every call. In many applications, those values are perfectly valid results, but the standard ||= idiom can't distinguish between:

• "This value hasn't been computed yet."
• "The value was computed and happened to be nil."
• "The value was computed and happened to be false."

As applications grow, other concerns start to appear:

• Thread safety
• Expiration and cache invalidation
• Methods with arguments
• Memory growth
• Shared caches
• Request-scoped caching
• Observability and metrics

Many developers end up reinventing these solutions over and over again.

Introducing SafeMemoize

SafeMemoize is a zero-dependency Ruby library that provides thread-safe memoization while correctly handling nil and false return values.

The goal wasn't to create yet another cache library.

Instead, the goal was to provide a safer and more capable alternative to the ad hoc memoization code that accumulates in many applications.

Some of the capabilities include:

• Thread-safe operation
• Correct handling of falsy values
• Argument-aware memoization
• TTL expiration
• Cache invalidation
• Shared and request-scoped caches
• External cache store support
• Metrics and instrumentation
• Rails integration

While the API remains intentionally simple, it provides enough flexibility to support everything from small scripts to larger Rails applications.

Getting Started

Adding SafeMemoize is straightforward:

gem "safe_memoize"

Then prepend the module and mark methods for memoization:

class UserService
  prepend SafeMemoize

  def current_user
    User.find_by(session_id: session_id)
  end

  memoize :current_user
end

That's all that's required.

Subsequent calls return the cached value without repeating the work.┄

Handling nil and false Correctly

One of the primary motivations behind SafeMemoize was ensuring that methods are computed exactly once, regardless of the value returned.

For example:

class FeatureFlags
  prepend SafeMemoize

  def enabled?
    ENV["NEW_FEATURE"] == "true"
  end

  memoize :enabled?
end

Even when the result is false, the method is evaluated only once.
This small difference eliminates an entire class of subtle bugs.

More Than a Single Instance Variable

Simple memoization works well for a handful of methods, but larger applications often need more control.

SafeMemoize provides support for things like:

• Expiring cached values after a configurable time.
• Limiting cache growth.
• Sharing values across instances.
• Integrating with Rails request lifecycles.
• Using Redis or Rails.cache as backing store.
• Observing cache behavior through metrics and notifications.

These capabilities make memoization practical in environments where simple instance variables eventually become difficult to manage.

Thread Safety Matters

Modern Ruby applications frequently process multiple requests concurrently.

Without synchronization, multiple threads may perform the same expensive work simultaneously, defeating the purpose of memoization.

SafeMemoize uses a per-instance mutex and double-check locking to ensure that expensive computations happen only once, even under concurrent load.

The result is a cache that behaves predictably under real-world workloads.

Designed for Ruby and Rails

Although SafeMemoize works in plain Ruby applications, many of the ideas behind the library came from Rails projects.

Request-scoped caching, instrumentation, and external cache stores make it easy to fit into existing Rails applications without introducing another large dependency.

At the same time, the library remains lightweight enough to use in service objects, scripts, background jobs, and standalone Ruby programs.

Why I Built It

I didn't set out to build a cache framework.

I simply wanted memoization that:

• Correctly handled nil and false.
• Was safe under concurrency.
• Scaled beyond a few instance variables.
• Worked naturally with Rails.
• Didn't require additional dependencies.

Over time, that evolved into SafeMemoize.

Because while memoization looks simple, production applications often need something a little safer than:

@value ||= expensive_operation

And sometimes, that one line deserves a little more help.