Safer Memoization
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.cacheas 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
nilandfalse. - 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.