Understanding the Components

Before diving into the implementation, let's understand the key components:

• Trigger: The specific event that causes a reward to be created (e.g., completing a trial booking)

• Source: The original cause that led to the reward (typically the referral)

• Recipient: The user or household that receives the reward

• Amount: The reward value, stored in cents for precision using the money-rails gem

The Core: The Reward Model

At the heart of our system is the Reward model:

class Reward < ApplicationRecord
  belongs_to :recipient, polymorphic: true
  belongs_to :trigger, polymorphic: true, optional: true
  belongs_to :source, polymorphic: true, optional: true

  monetize :amount_cents

  enum reason: {
    trial_start: 'trial_start',
    sub_complete: 'sub_complete',
    signup_discount: 'signup_discount'
  }, _prefix: true

  scope :unredeemed, -> { where(redeemed_at: nil) }

  # ... methods for creating specific rewards ...
end

The Rewardable Concern

To make it easy to add reward functionality to different models, we created a Rewardable concern:

# app/models/concerns/rewardable.rb

module Rewardable
  extend ActiveSupport::Concern

  included do
    has_many :rewards, as: :recipient
  end

  def total_earned
    Money.new(rewards.sum(:amount_cents), "CAD")
  end

  def unredeemed_rewards
    rewards.unredeemed
  end

  def redeem_rewards!
    unredeemed_rewards.update_all(redeemed_at: Time.current)
  end
end

Extending the Referral Model

We extended the Refer gem's Referral model to integrate with our reward system:

module ReferralExtensions
  extend ActiveSupport::Concern

  included do
    has_many :rewards, as: :source
  end

  def create_trial_rewards(trial_booking)
    Reward.create_for_trial_start(self, trial_booking)
  end

  def complete_subscription(subscription)
    Reward.create_for_sub_complete(self, subscription)
  end
end

# In config/initializers/refer.rb
Rails.application.config.to_prepare do
  Refer::Referral.include ReferralExtensions
end

Triggering Rewards

We set up our Booking model to trigger rewards when a booking is completed, as an example:

class Booking < ApplicationRecord
  after_save :create_trial_start_reward, if: :status_changed_to_completed?

  private

  def create_trial_start_reward
    referral = Refer::Referral.find_by(referred: household.owner)
    Reward.create_for_trial_start(referral, self) if referral
  end

  def status_changed_to_completed?
    saved_change_to_status? && completed?
  end
end

Conclusion

This flexible reward system allows us to easily add new types of rewards and associate them with different actions in our application. The use of polymorphic associations provides the flexibility to link rewards to various models, while the money-rails gem ensures precise handling of monetary amounts. The system has proven to be robust and easily extendable as our referral program grows.

The combination of the Refer gem for handling referrals and our custom reward system has created a powerful tool for incentivizing user growth and engagement on our platform.

Setting Up the Refer Gem

First, we added the Refer gem to our Gemfile:

gem "refer"

After running bundle install, we generated the necessary migrations:

rails generate refer:install
rails db:migrate

This set up the basic database structure for tracking referrals.

Configuring the Referral Code Generator

We customized the referral code generation in an initializer file:

# config/initializers/refer.rb

Refer.code_generator = lambda do |referrer|
  get_existing_code(referrer).presence || generate_new_code(referrer.id)
end

Refer.param_name = :code

private

def get_existing_code(referrer)
  referrer.referral_codes.last&.code
end

def generate_new_code(referrer_id)
  letters = ("A".."Z").to_a.sample(4).join
  padded_id = referrer_id.to_s.rjust(4, "0")
  "#{letters}-#{padded_id}"
end

This creates unique, readable codes combining random letters and the referrer's ID.

Integrating with User Model

We added the has_referrals macro to our User model:

class User < ApplicationRecord
  has_referrals
  # ... other code ...
end

Handling Referrals in the Controller

We updated our RegistrationsController to handle referrals during sign up:

class RegistrationsController < ApplicationController
  def create
    @user = User.new(user_params)
    if @user.save
      refer @user
      start_new_session_for @user
      send_welcome_email
      redirect_to after_authentication_url, notice: "Welcome to Cravd!"
    else
      render :new, status: :unprocessable_content
    end
  end
end

Handling Referrals in the Controller

In our ReferralsController, we implemented two key methods to manage referral codes and cookies:

class ReferralsController < ApplicationController
  set_referral_cookie only: [:show], if: -> { Current.user.blank? && !browser.bot? }
  before_action :set_referral_code, only: [:index, :show]

  private

  def set_referral_code
    return unless Current.user
    @referral_code = Current.user.referral_codes.last || Current.user.referral_codes.create
  end
end

The set_referral_cookie method is used to store the referral code in a cookie when it's present in the request parameters, and set_referral_code method is used to create or retrieve a referral code for the current user. It’s used in the referrals controllers where I want to display the user's referral code.

Conclusion

With these pieces in place, we now have a functional referral system. Users can generate unique referral codes, share them, and we can track successful referrals. This implementation provides a solid foundation for our referral program, which we'll build upon to create a comprehensive reward system.

Cost Surge

What started as an "elegant solution" quickly became a concern. By July 2024, ElastiCache costs had skyrocketed to $120.53, pushing our total AWS expenses to $197.811. The graph clearly shows how ElastiCache dominated our infrastructure costs, accounting for over 60% of monthly expenses.

The Solution

After successfully implementing Solid Queue and following the release of Solid Cable at Rails World 2024, we pivoted to this database-backed alternative for real-time features. This eliminated our Redis dependency while maintaining full functionality. The data shows remarkable improvements:

• Monthly AWS costs decreased from $197.81 to $74.55

• Infrastructure costs reduced by approximately 62%

• Complete elimination of the $120.53 monthly ElastiCache expense

Beyond the Numbers

The switch to Solid Queue significantly reduced our infrastructure complexity. By eliminating Redis, we've simplified our stack, making it easier to maintain, debug, and scale. This change aligns with Rails' philosophy of convention over configuration, keeping things simple and streamlined. Following this success, we integrated Solid Cache, completing the Solid trifecta.

Key Takeaway

This migration reinforces a valuable lesson: staying aligned with framework defaults often leads to both technical and financial benefits. Our tech stack is now simpler, more maintainable, and more cost-effective while maintaining all the functionality our application requires.

The cost breakdown graph demonstrates this transformation, showing sustained lower costs from October 2024 onward, with stable expenses around $75/month