Design an in-app promotion decision engine
PremiumMobile systemMedium
- On device rules engine
- Frequency capping
- Surface arbitration
Quick answer
This mobile system interview question asks you to design an in-app promotion decision engine. Aim for a design that meets its requirements at the stated scale, then explain its main components, data flow and trade-offs. Interviewers want to see how you scope the problem, size it and defend each choice.
The problem
Design an in-app promotion decision engine for a mobile PDF reader app: it decides which promotion, if any, to show at each moment (banner, dialog, ad slot or feature promo). The hard parts are deciding on the device in milliseconds, working offline, and never annoying users or interrupting real work.
Several teams run campaigns: upgrade offers, feature tips such as try the new scan tool, partner ads in one fixed slot for free users, and short surveys. Today each team shows its own pop-ups, and some users see three in one session. The engine is one shared layer that every surface asks before it shows anything. You cover both the high-level design (HLD) and the low-level design (LLD) of the engine.
What must an in-app promotion decision engine do?
- Decide per trigger: On a trigger (app open, document opened, page N reached, file saved, feature used) return at most one promotion per surface, or none.
- Targeting and caps: Check rules (plan, app version, locale, days since install, feature usage) and per-campaign caps and cooldowns using only on-device data.
How well must it do it?
- Fast decision: A decision takes under 10 ms off the main thread; if the creative is not ready within 300 ms of the trigger, show nothing.
- Respectful UX: No promotion interrupts editing, signing or form filling, and dismissed promotions respect their cooldowns.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- On device rules engine
- Frequency capping
- Surface arbitration
- Interruption budget
- Remote config bundle
- Creative prefetch
How you’ll practise
- Requirements
- App architecture
- Data and offline sync
- Networking and push
- Performance, battery and releases
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any mobile system design round.
- Clarifies the requirements before drawing anything
- Uses a few numbers that actually change the design
- Draws a clear path from the client to storage
- Picks storage and caching with reasons, not by habit
- Explains what breaks first under load and how to fix it
- States trade-offs openly instead of claiming a perfect design
Questions people ask about this interview question
- Which design type is this question?
- It is a mobile system question. You design an in-app promotion decision engine and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Medium. Entry-level engineers can practise it, but it expects you to reason about requirements and trade-offs, not only list components.
- What should I cover first?
- Start with the requirements: what the system must do, how well it must do it and which numbers change the design. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team