Should i make a seperate app to send push notifications to 40-50k users in RoR App or use background

I have a rails application that is in fact a backend of a popular IOS
application which have a user base of 200k users who need to be
time to time.

Daily 40-50k users will be notified using push notifications. These
notifications will berealtime and scheduled ones. eg: if a new users
signs up he will be notified within few seconds. eg: scheduled
notifications will run at 10 pm daily with limited users ranging 10k-30k
sometimes more upto 100k.

I also will be doing business reporting to generate list of users
fulfilling certain criteria and it requires firing mysql queries that
take upto 1-2 minutes of time.

My area of concern is should i have a seperate application with
mirror db
to send push notifications to these users so my IOS users
feel lag while using this application when push notifications are
or business reporting query is triggered.

Or should i use background jobs like Rails Active job, Sidekiq or
to perform push notifications and triggering business reporting

Is background jobs in rails so powerful that it can manage this
and doesn’t let App users to feel lag in experience.

My application stack is:

Rails: 4.1.6Ruby: 2.2
DB: MysqlPaaS: AWS Elastic Beans
IOS Push gem: Houston

A separate app doesn’t sound like a sensible solution. I’d do the

  1. Use a job queue, roll out the feature to a subset of users, identify
    performance bottlenecks and optimise them.
  2. Roll out to a larger subset of users and repeat 1.
  3. When you’re confident that this works good roll out the feature 100%.

At any point in time you can offload database-intensive operations to a
read-only replica. I wrote an article (
how to do this on Heroku PostgreSQL but the technique applies to other
RDBMs as well.

Greg Navis
I help tech companies to scale Heroku-hosted Rails apps.
Free, biweekly scalability newsletter for SaaS CEOs