ruby on rails - Should i make a seperate app to send push notifications to 40-50k users in RoR App or use background jobs -
i have rails application in fact backend of popular ios application have user base of 200k users needs notified time time.
daily 40-50k users notified using push notifications. these push notifications realtime , scheduled ones. eg: if new users signs notified within few seconds. eg: scheduled notifications run @ 10 pm daily limited users ranging 10k-30k or more upto 100k.
i doing business reporting generate list of users fulfilling criteria , requires firing mysql queries take upto 1-2 minutes of time.
my area of concern should have seperate application seperate mirror db send push notifications these users ios users doesnt feel lag while using application when push notifications triggered or business reporting query triggered.
or should use background jobs rails active job, sidekiq or sucker punch perform push notifications , triggering business reporting queries.
is background jobs in rails powerful can manage condition , doesn't let app users feel lag in experience.
my application stack is:
rails: 4.1.6 ruby: 2.2 db: mysql paas: aws elastic beans ios push gem: houston
in opinion, there several factors affect decision.
1. service need keep many persistent connections?
if answer yes, use language has better asynchronous io (like node.js) implement push service.
if answer no, means send requests third-party services (like apns), consider next factor.
2. have reuse domain model in push service?
if answer yes, stick active job + sidekiq.
if answer no, means uses fields (like id
, name
) of table (like users
), consider next factor.
3. server have limited memory resource?
a rails processes consumes several hundreds of mb of memory, , sidekiq requires separate rails process can't preforked (which means not share memory rails app).
so if answer yes, consider create separate lightweight push service.
as mirror database, if have heavy query before push, use mirror database.
Comments
Post a Comment