SFMC Architecture and Mobile Messaging Interview Questions

This is the senior round. By the time an interviewer reaches these questions, they have accepted that you know what a data extension is. What they want now is to hear you make a decision and defend the cost of it. The mobile half checks whether you have actually run SMS and push in production, including consent handling, which is where most candidates go quiet. The architecture half is a design conversation, often framed around a consumer app at scale, where there is no single correct answer and the interviewer is listening to your reasoning. Twenty-four questions below, taken from real interview rounds, with answers written the way an architect would give them.

MobileConnect and MobilePush interview questions

What is MobileConnect?

MobileConnect is the SMS and MMS application inside Mobile Studio. It holds its own contact record keyed on the mobile number, tracks a subscription status for every combination of contact, code and country, and sends either from a list, from an SMS activity inside a journey, or through the API.

Two things make it different from Email Studio in practice. First, subscription is per code and per country, not a single global opt-in, so a contact who agreed to receive messages on one code has not agreed on another. Second, the message body is plain text with a hard segment boundary. Once you cross the single segment length the message splits and you pay for every part, and non-Latin characters shrink the segment length considerably, which matters the moment you send in a regional Indian language.

So when you write SMS copy, the personalisation you add is not free. Every extra character has a rupee value attached to it at volume.

What is Shortcode vs Longcode?

Both are the sending address a recipient sees and replies to. The difference is throughput, cost and how they are provisioned.

The senior follow up is usually about India, and this is where candidates guess. Do not. The correct answer is that the Indian market does not run on short codes the way North America does. Commercial SMS here is delivered against a registered sender header, and the regulator requires the sender entity, the header and the message template to be registered before traffic flows, with the operator enforcing that at the gateway. Consumer preference and do-not-disturb registrations also have to be honoured. State the obligation, say that your delivery partner and legal team confirm the current registration rules for the account, and move on. An interviewer respects that far more than a confidently wrong number.

What is SMS Send Classification?

An SMS send classification bundles the sending configuration for a message so that a marketer picking it from a dropdown cannot accidentally send under the wrong conditions. It ties together the code the message goes out from, the country or countries in scope, and the classification of the message itself, meaning whether it is promotional or transactional.

That classification is not cosmetic. It decides whether opt-in is enforced and whether quiet hour and blackout window rules apply. A one time password sent under a promotional classification gets suppressed for anyone who has opted out of marketing, and the customer never gets into the app. A promotional offer sent under a transactional classification reaches people who never consented, which is a compliance problem rather than an engagement problem.

In a well run account, transactional and promotional SMS run through separate classifications, separate codes where the budget allows, and separate automation paths, so that a marketing incident cannot take down the OTP channel.

What is the data view for SMS tracking?

The main one is _SMSMessageTracking. Around it sit _SMSSubscriptionLog for opt-in and opt-out events, _SMSConversationTracking for inbound message flows, and _MobileAddress and _MobileSubscription for the contact and subscription state.

You query these with SQL in Automation Studio, the same way you would query _Sent or _Open on the email side.

SELECT
    t.MobileSubscriptionKey,
    t.SubscriberKey,
    t.MessageID,
    t.MessageStatus,
    t.MessageDate
FROM _SMSMessageTracking t
WHERE t.MessageDate >= DATEADD(DAY, -7, GETDATE())

The point to raise before the interviewer does is retention. Data views hold a rolling window of history, not the life of the account. If your reporting or your audit trail needs SMS history beyond that window, you schedule a query activity that writes the rows into your own data extension, and from there into the warehouse. Teams find this out the month the compliance team asks for last year's opt-out log.

What is MobilePush?

MobilePush is the application for sending notifications to a mobile app you own. It needs the Marketing Cloud SDK compiled into that app, because the device has to register itself and hand back a push token before you can reach it.

The design consequence is that push is cheap but unreliable in coverage, and SMS is reliable in coverage but expensive and regulated. That is exactly why the fallback pattern in the architecture section exists.

How do you configure Push Notification?

The sequence, and interviewers do ask for it in order:

1. Create the app record in MobilePush and get the app ID and access credentials.
2. Upload the platform credentials. For iOS that is the APNs key or certificate, for Android the Firebase Cloud Messaging credentials.
3. Integrate the SDK into the app build and initialise it with those values.
4. Have the SDK register the device. It sends the token back and you set the contact key at this point, usually the same customer identifier you use everywhere else.
5. Build the message in MobilePush, or add a push activity inside a journey.
6. Choose the audience. All subscribers, a tag based audience, or a data extension audience.
7. Test to a registered device before anything else. Push behaves differently on a real handset than in any preview.

Step four is the one that gets skipped, and then nobody can work out why push cannot be personalised or joined to the rest of the contact record.

What is MobilePush SDK?

The SDK is the library inside your mobile app that does the work Marketing Cloud cannot do from the outside. It registers the device and keeps the push token current when the OS rotates it, sets and updates the contact key, carries attributes and tags used for audience building, receives and renders notifications, drives in-app messages and the message inbox, and reports engagement events back.

This is a favourite question for a reason. As the trainer here puts it, candidates know the syntax but not the execution, meaning they can quote the method name but not say when it runs, where it runs and what data it can reach. So be precise. SDK code runs on the handset, inside your app, with the app developer's release cycle. If you want a new attribute available for segmentation, that is an app release and a store review, not a change you make in the platform on Tuesday afternoon. Saying that out loud tells the interviewer you have shipped this.

How do you personalize SMS messages?

The same personalisation strings and AMPscript you use in email work in an SMS body, resolved against the sending data extension or the MobileConnect contact attributes.

%%[
VAR @name, @pickup
SET @name = IIF(EMPTY(FirstName), "there", FirstName)
SET @pickup = Lookup("Booking_Latest", "PickupPoint", "ContactKey", _subscriberkey)
]%%
Hi %%=v(@name)=%%, your ride to %%=v(@pickup)=%% is confirmed.

Three habits separate a production SMS template from a demo one. Always set a fallback for a null value, because an empty personalisation in SMS reads as a broken message rather than an awkward one. Keep substituted values short, because a long city name can push you into a second segment and double the cost of the campaign. And where the market requires registered message templates, as India does, the variable portions have to sit inside the approved template, so personalisation is designed at registration time and not improvised later by a marketer.

What is Keyword Management in SMS?

Keywords are the inbound words a recipient can text to your code, and each one is configured with a response and an action. A subscribe keyword opts the contact in and sends the welcome message. STOP and its variants opt them out. HELP returns the support response. Campaign keywords capture a specific intent, such as texting a word to enter a promotion, and can be wired to an entry event so the journey starts from the inbound message.

The architectural detail worth raising is collision. Keywords are unique per code. If several business units share one code, they are sharing one keyword namespace, and two teams both wanting OFFER is a governance conversation, not a technical one. On a multi-brand account this is one of the arguments for separate codes per brand despite the cost.

How do you manage SMS opt-outs?

Opt-out is handled on three levels, and a good answer covers all three.

At the platform level, standard opt-out keywords are recognised on the code, the platform sends the confirmation response, and the contact's subscription status for that code and country moves to opted out. Every one of these events lands in _SMSSubscriptionLog.

At the send level, the suppression is applied automatically for promotional classifications, but you still build your own suppression into the audience query, because you want a send to be correct before it reaches the platform and not only because the platform caught it.

At the data level, you keep your own consent record. Channel, purpose, timestamp, source of the consent, and where it came from. The platform tells you the current status. Your consent record tells you how you got there, which is what an audit asks for.

The obligation to honour an opt-out is immediate and it applies to the sender, not to the tool. Where a code is shared across business units, decide explicitly whether an opt-out in one unit suppresses the others, because the regulator's view of who the customer opted out from is usually broader than the org chart's.

What is MMS?

MMS carries an image, audio or video instead of plain text through the same code and the same subscription model. Support is not universal. It depends on the country, the carrier and whether the code itself is enabled for MMS, and the per message cost is significantly higher than SMS.

For a design answer, treat MMS as an enhancement and never as a dependency. Build the campaign so that the SMS text with a short link carries the full meaning on its own, and let the media improve the message where it is supported. That way the fallback path is the normal path, and nothing breaks in the markets where MMS is unavailable.

How do you track push engagement?

Engagement comes back from the SDK, not from a mail server, so the shape of the data is different. Message level statistics are available in the MobilePush reports and through Analytics Builder, device and tag state sits in the push data views, and the richer behavioural picture comes from the app analytics events you send alongside.

Two caveats worth volunteering. An open is only recorded when the user interacts with the notification, so a push that appears on the lock screen and is dismissed is not an open in the way an email pixel fire is. And push tokens go stale when an app is uninstalled or notifications are switched off, so your addressable audience quietly shrinks between campaigns. If you are not tracking the size of the registered and enabled device base over time, your push open rate will look like it is improving when it is only the denominator that changed.

What the interviewer is actually checking on mobile

• Whether you have handled consent as a system rather than as a tick box, and whether you know the obligation sits with the sender.
• Whether you know that SMS costs money per segment and design copy accordingly.
• Whether you understand that push needs an app release cycle and that the SDK runs on the handset, outside your control.
• Whether you can name the tracking data views and say what happens when the retention window passes.
• Whether you treat transactional and promotional traffic as separate paths with separate failure consequences.

SFMC architecture and system design interview questions

These are asked as open design problems, usually set at consumer app scale. The interviewer is not marking you against a reference architecture. They are checking whether you state assumptions, choose, and then say what the choice costs. The trainer's line applies directly here: specificity creates credibility. "We used a queue" is worth nothing. "We put a queue in front of the trigger service because the booking system emits in bursts and the messaging API rate limits us" is worth the whole round.

How will you architect real-time ride booking at massive scale?

Start by splitting the problem, because a single service does not survive this.

The booking record itself is a state machine and it needs strong consistency. One trip, one owner, transitions that are idempotent so a retried request does not create a second booking. Everything else can be eventually consistent.

Around that, partition by geography. A ride in Pune has nothing to do with a ride in Chennai, so shard by city or region and you get horizontal scale without cross-shard coordination. Driver availability lives in an in-memory store with a short expiry, because it is worthless three minutes later. Completed trips go to durable storage.

Between the components, put an event log. The booking service publishes state changes, and pricing, notifications, analytics and marketing all consume from it rather than calling back into the booking service. That single decision is what keeps a marketing burst from degrading the booking path.

The trade-off to say out loud: you are accepting eventual consistency across most of the system in exchange for the booking core staying small, fast and strongly consistent. The visible cost is that a driver's app and a rider's app can disagree for a second, and you handle that in the UI rather than in the database.

How will you handle driver location updates efficiently?

This is a write volume problem where each individual write is almost worthless. Design accordingly.

On the device, make the update frequency adaptive. A driver parked at home does not need the same ping rate as a driver mid-trip in traffic. Batch several points into one payload and use a compact binary format over a persistent connection rather than an HTTP request per ping.

On the server, the current position goes into an in-memory geospatial store with a time to live, because only the latest position matters for dispatch. The historical trail is sampled, not stored point for point, and written asynchronously for trip reconstruction and billing disputes.

The trade-off is accuracy against cost, and the right answer depends on what the location is for. Dispatch needs freshness and tolerates coarse accuracy. Billing needs an accurate trail and tolerates a delay of minutes. Splitting those two consumers lets you be cheap on one path and careful on the other.

How will you design nearest-driver search?

Index drivers into geospatial cells, using geohash or a similar cell scheme, held in memory and partitioned by city. A search reads the rider's cell and its neighbours, which gives you a candidate set in a single lookup rather than a scan.

Then re-rank. Straight line distance is a cheap filter and a poor answer, because a driver five hundred metres away across a river is twenty minutes away. So the shortlist goes to a routing or ETA service that scores by actual travel time, and you dispatch on that.

The trade-off is how wide you search. A narrow radius returns fast and sometimes finds nobody. A wide radius always finds someone and wastes ETA computation on drivers who will never be assigned. Expanding rings, where you widen only if the first ring fails, gives you the fast common case and a correct worst case.

How will you isolate marketing traffic from ride-booking core system?

One rule above everything: marketing never queries the transactional database. It consumes events or a change data capture feed into its own store, and every marketing read happens against that copy. If the segmentation query is slow, the worst outcome is a late campaign, not a slow booking.

Inside Marketing Cloud, the isolation question becomes business unit design, and this is where the interviewer will push.

For a multi-brand or multi-country account, the pattern that holds up is a parent business unit that owns shared data and governance, with child business units per brand or per country. The parent holds shared data extensions, the shared suppression lists and the data model. Each child holds its own sends, sender profiles, codes, consent state and users.

Splitting by country is usually the stronger split, because country is what drives sender registration, consent rules, language and send time. Splitting by brand within a country is a branding and access decision rather than a compliance one.

What it costs you is reporting. Tracking data views are scoped to the business unit, so once you have twelve child units you no longer have one place to answer "how did the campaign perform across the group". You get that back one of two ways. Either you run a scheduled extract per business unit into a warehouse and report there, which is the honest answer at scale, or you consolidate results into parent level data extensions and accept the lag and the maintenance. Either way, cross business unit reporting is a thing you build, not a thing you get.

The related decision is when a shared data extension beats duplicating one per business unit. Share when the data is genuinely the same across units and correctness depends on it being the same, which means the global suppression list, the single product catalogue, the reference tables, the consent state. Duplicate when the data is unit specific, when volume is large and each unit only needs its slice, or when a child unit's users must not be able to see another unit's records. The cost of sharing is that everyone inherits one schema and one change window, and a schema change in the parent has to be coordinated across every unit that reads it. The cost of duplicating is drift, and drift in a suppression list is a compliance incident.

How will you scale millions of notifications daily?

The question behind the question is what you do when send volume outgrows the current setup.

The generic design is a queue and a pool of stateless workers, with rate limiting per channel to respect provider throughput, priority lanes so transactional traffic overtakes promotional, and backpressure so that a backlog slows producers instead of collapsing the workers. Add a deduplication key per contact per message per window, because at this volume a retry storm sends the same SMS three times and customers notice.

Inside Marketing Cloud, the specific moves are these. Move from large list sends to triggered sends and journeys so the load spreads across the day instead of stacking on one send definition. Use send throttling where the receiving infrastructure or the contact centre cannot absorb a spike. Push segmentation upstream, so the send window is spent sending rather than running a query, ideally with the audience already materialised by a scheduled SQL activity or by Data Cloud. Split large automations so one long running step does not block the rest. And on the email side, plan the IP and domain warming before the volume arrives, not after the complaints do.

The trade-off is personalisation depth against throughput. Every lookup inside the message body is work done per recipient at send time. At a few thousand recipients nobody notices. At several million, moving those lookups into the audience build, so the message reads pre-computed columns, is the difference between a send that finishes in the window and one that does not.

How will you design push + SMS fallback within 10 seconds?

Model it as a per message state record with a deadline, not as two sends.

When the notification is created, write a record with the message id, the contact, the channel attempted and an expiry timestamp. Send the push. Put a delayed item on a timer queue due at the deadline. If the app acknowledges before then, mark the record delivered and the timer finds nothing to do. If the deadline arrives unacknowledged, the fallback worker enqueues the SMS.

The critical technical point, and the one that separates a senior answer, is what counts as acknowledgement. A success response from the push provider only proves the provider accepted the message. It says nothing about the handset. The only trustworthy signal is the app itself reporting receipt, which means the SDK or your app code posts an ack. If you build the fallback on the provider response, you will suppress the SMS for users whose devices never got the push.

The trade-off is the width of the window. A short window meets the service level and pays for duplicate SMS to users whose push was simply slow. A long window is cheaper and misses the promise. Ten seconds is a product decision, so state the cost of it and let the business choose.

Idempotency ties it together. Both channels carry the same message id so the app can suppress a duplicate display, and the state record is updated with a conditional write so two workers cannot both fire the fallback.

How will you implement in-house segmentation engine?

Build it in three layers.

Underneath, a columnar warehouse holding the customer profile and the behavioural events, refreshed from the event log. Above that, segment definitions stored as declarative rules and compiled to SQL, versioned, so the audience for a campaign that ran in March can be reproduced in September. On top, a materialisation step that writes the resulting audience to a table with a freshness timestamp attached, and refreshes incrementally rather than rebuilding everything.

The contact model is the part that decides whether this works, and it is the same question as how you model contacts across channels. One canonical person id, chosen from a system that will not change, usually the customer account id. Every channel address hangs off it as an attribute: email, mobile number, device token, app id, social identifier. They are not separate people.

In Marketing Cloud terms, that id is the contact key, and the discipline is that it is the same value in Email Studio, in the MobileConnect contact, and in the value the MobilePush SDK sets on the device. When those disagree, you get duplicate contacts, inflated contact counts and a suppression that applies on one channel and not the other. Contact Builder holds the attribute groups per channel, linked back to that single key.

Real time is the expensive decision. A segment that must reflect an event within seconds needs a streaming path and its own infrastructure. A segment that can be an hour old needs a scheduled query. Most campaigns are the second kind, and the interviewer wants to hear you say that before you design the first kind.

How will you ensure consent/DND compliance at scale?

Make consent a service, not a column.

One consent store, holding channel, purpose, status, timestamp, source and the evidence of capture. Every dispatch path consults it at send time. No campaign tool keeps its own copy, because a copy is a snapshot and a snapshot goes stale between the segment build and the send.

Then scrub against the regulator's preference registry before dispatch, keep transactional and promotional paths separate because they carry different obligations, and log every decision, including the suppressions, so you can show why a message was not sent as easily as why it was.

For India specifically, describe the obligation rather than reciting a rule. The sender entity, the header and the message template have to be registered with the telecom framework before commercial SMS is delivered, consumer preference registrations have to be honoured, and the enforcement happens at the operator. The practical consequence for your design is that a marketer cannot compose a new promotional SMS on the day of the campaign, so the template lifecycle becomes part of the platform, with registration status held as a field and a send blocked when it is not approved.

The honest position in an interview is that you build the mechanism and your compliance and legal team confirm the current rule set. Nobody expects an architect to quote regulation from memory. They do expect you to have built the hook for it.

How will you manage A/B testing internally?

Assignment first. Bucket with a deterministic hash of the contact id combined with the experiment id, so the same person always lands in the same arm, the assignment is reproducible without storing a table, and two experiments do not correlate with each other.

Then log exposure at the moment of send, not at the moment of segment build, because people who were suppressed never saw the test and must not be counted.

Decide the single success metric before the send goes out, and decide the sample size before as well. The common failure is to check results hourly and stop when the numbers look good, which manufactures a winner out of noise.

Keep a permanent holdout, a small group excluded from the campaign entirely. Message level A/B tells you which subject line won. Only a holdout tells you whether the campaign was worth running at all.

The trade-off against the built in A/B test in the tool is honest: the built in test is faster to set up and perfectly adequate for a subject line. It cannot easily give you a holdout that persists across campaigns or an experiment that spans channels, which is why large programmes end up running assignment themselves and using the tool only to deliver.

How will you ensure real-time transactional triggers?

Event driven, with a buffer, and kept away from marketing.

The core system emits an event. A thin trigger service maps that event type to a template and calls the messaging API. A queue sits in front of the trigger service to absorb bursts, a dead letter queue catches what fails repeatedly, and every request carries an idempotency key derived from the event id so a replay does not send twice.

In Marketing Cloud, this is the triggered send and transactional messaging path, and it must be physically separate from the promotional automations. Different send definitions, different sender profiles, ideally a different IP for email and a different code for SMS. The reason is operational: when a promotional automation gets stuck behind a large query, the OTP must still go out.

The trade-off worth stating is synchronous against asynchronous. Calling the messaging API synchronously from the core gives you a message id back immediately and couples your booking flow to the vendor's availability. Publishing to a queue and letting a worker call the API keeps the core independent, at the price of owning retry, ordering and observability yourself. For anything a customer is waiting on, the queue with a tight consumer is usually right, because the core staying up matters more than the receipt.

How will you design Journey Automation without external tools?

A journey is a state machine per contact per journey version, so build the four parts it needs.

A state store holding where each contact is, when they entered, and which version they are on. A scheduler for waits, which is the hard part at scale, implemented as a delayed queue partitioned by due time rather than a table you poll. An evaluation service for decision splits, reading from the profile store at the moment of evaluation rather than from a snapshot taken at entry. And an exit layer covering goals, suppression and re-entry rules.

Three problems bite in production. Versioning, because a journey changes while thousands of people are inside the old one, and you have to decide whether they finish on the old version or get migrated. Wait accuracy, because a wait until a send window at scale means millions of items becoming due in the same minute. And suppression timing, because consent checked at journey entry is meaningless three weeks later at the send step.

Say the build cost honestly. This is a serious engineering programme and Journey Builder gives you it on day one, at the price of working inside its entry event and decision model. The case for building your own is usually that your entry events are too specific to the product, or that you need decision logic Journey Builder cannot express. The case against is that you will spend a year rebuilding wait timers.

The trainer's warning matters most on this question. Claim you built a journey engine and the interviewer goes five levels deep. Which store, what requirement drove it, why that over Journey Builder, and what exactly was your part in it. Fake experience does not survive the fourth question.

How will you manage high-availability marketing infrastructure?

Start by refusing to treat all of it as equally critical. Transactional messaging needs high availability. A promotional campaign needs to be recoverable, not instantaneous. Stating different recovery objectives for the two paths is the answer, because it is what lets you spend money where it matters.

For the parts that must stay up: run workers stateless and across availability zones so any instance can be lost, use queues as the buffer that absorbs a partial failure, avoid a single scheduler as a point of failure, and keep the event log as the replay source so a consumer that lost data can rebuild from it.

For the parts that can degrade: shed promotional load first. When the SMS aggregator is slow, promotional traffic pauses and transactional continues. That switch should be a configuration change an on-call engineer can make, not a code deploy.

Then the parts everyone forgets. A second SMS or push provider configured and tested before the outage, because the day of the outage is not when you integrate one. Monitoring on queue depth, send latency and provider error rate, with alerts on the rate of change and not only on absolute values. And a runbook that says who decides to fail over.

What the interviewer is actually checking on architecture

• Whether you state assumptions and constraints before you draw anything.
• Whether you can name the cost of your own design, especially the reporting cost of a business unit split.
• Whether you separate transactional and promotional paths, in infrastructure and not only on a slide.
• Whether you know when to build and when to accept the platform's model, and can argue both sides.
• Whether the experience is real, because the follow up questions will go four or five levels into one decision.

Preparing for the senior round

The pattern across both halves of this round is the same. The interviewer is not testing recall. They are testing whether you have made these decisions with money and uptime attached to them, and whether you can explain the decision in the order a senior person explains it: the situation, the approach, the reason for that approach over the alternative, and the result.

Pick two of these questions, the business unit design one and the push fallback one, and write your own answer out in full, with the trade-off stated. Then say it out loud. The gap between knowing this material and being able to present it under questioning is the gap that costs people the offer, and it closes only with practice.

If you want that practice with real project work behind it, the Salesforce Marketing Cloud training at RizeX Labs in Pune covers Mobile Studio, Contact Builder and multi business unit architecture as build exercises rather than as slides, with interview preparation on the same questions above.