Architect interviews are a different beast entirely. I remember my first architect interview - I walked in thinking I'd crush it because I knew Salesforce inside and out. Then they asked me to design a system for a company with 50 million records, real-time integrations with five different systems, and users across three continents. I realized quickly that being a great developer doesn't automatically make you a great architect.
Here's the truth: architect interviews aren't about reciting features or writing perfect code. They're about seeing the big picture, making trade-offs, and designing systems that work at scale. The interviewers want to know if you can take messy business requirements and turn them into a coherent, scalable architecture that won't fall apart in six months.
These are the questions that keep coming up in architect interviews, with the kind of thinking that separates good architects from great ones.
Before we dive in, let me set expectations. Architecture questions rarely have one "right" answer. Instead, they're testing:
The best answers start with clarifying questions. Don't just dive into a solution - ask about users, data volumes, integrations, and constraints.
This is the classic "big data" question. They're testing whether you understand Salesforce limits and when to architect around them.
My approach - start with questions:
The architecture I'd propose:
┌─────────────────────────────────────────────────┐
│ Active Accounts (Salesforce) │
│ Recent/High-Value: ~5-10M records │
│ - Fast access │
│ - Full sharing rules │
│ - Real-time reporting │
└──────────────────┬──────────────────────────────┘
│
│ Archive older records
▼
┌─────────────────────────────────────────────────┐
│ Archive Storage (Big Objects/Heroku) │
│ Historical/Inactive: ~40-45M records │
│ - Lower cost storage │
│ - Accessible via APIs │
│ - Batch reporting only │
└──────────────────┬──────────────────────────────┘
│
│ Compliance backups
▼
┌─────────────────────────────────────────────────┐
│ Cold Storage (AWS S3/Archive) │
│ Long-term retention for compliance │
└─────────────────────────────────────────────────┘
Key architectural decisions:
Performance considerations:
"I worked on a project exactly like this. We kept 3 years of data in Salesforce (about 8M records) and archived everything older to AWS S3 via Heroku Connect. Users could still search archived data through a custom Lightning component that hit our Heroku API. Saved the company about $200K annually in storage costs."
Integration questions are huge in architect interviews. This tests whether you understand the full integration landscape, not just "make an API call."
Questions I'd ask first:
Architecture options and trade-offs:
| Pattern | When to Use | Pros | Cons |
|---|---|---|---|
| Platform Events | Near real-time, fire-and-forget | Native, scalable, decoupled | 24-hour retention, no guaranteed delivery order |
| Change Data Capture | Need to track all changes | Automatic, captures all field changes | Limited filtering, all-or-nothing per object |
| Outbound Messages | Simple, guaranteed delivery needed | Built-in retry, no code | 24-hour timeout, limited throughput |
| Middleware (MuleSoft) | Complex transformation, multiple systems | Enterprise features, monitoring, error handling | Additional cost and complexity |
My recommended architecture:
Salesforce Middleware ERP
─────────────────────────────────────────────────────────
Order Created/Updated
│
│ Platform Event Published
▼
[Order Event]───────────────►[MuleSoft]
│ • Transform data
│ • Apply business rules
│ • Log transaction
│ • Error handling
│
▼
[ERP API Call]
│
├─Success─►Update Order Status
│ in Salesforce
│
└─Failure─►Queue for Retry
Alert support team
◄───────────────────────────────────────────────────────
ERP Order Update
│
│ Webhook/Polling
▼
[MuleSoft Listener]
│ • Validate payload
│ • Transform to Salesforce format
│ • Dedupe check
▼
[Salesforce REST API]
│
└─Updates Order
Critical design elements:
"Here's something I learned the hard way: always implement a reconciliation process. Even with perfect real-time sync, things get out of sync. We ran a nightly batch job that compared order statuses between systems and flagged discrepancies. Caught issues that would have otherwise gone unnoticed for weeks."
This question tests strategic thinking. The answer isn't always "use one org" even though that's often the default recommendation.
Single Org vs Multiple Orgs - The Trade-offs:
When ONE org makes sense:
When MULTIPLE orgs make sense:
A real-world example I designed:
Global manufacturing company with three divisions:
┌─────────────────────────────────────────────────┐ │ PRODUCTION DIVISION ORG │ │ • B2B Sales │ │ • Long sales cycles │ │ • Custom manufacturing quotes │ └─────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────┐ │ CONSUMER DIVISION ORG │ │ • B2C E-commerce │ │ • High volume transactions │ │ • Marketing Cloud integration │ └─────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────┐ │ SHARED SERVICES (Master Data) │ │ • Master Account/Contact data │ │ • Product catalog │ │ • Syncs to division orgs nightly │ └─────────────────────────────────────────────────┘
Why we chose multiple orgs:
How we connected them:
"The key insight: multiple orgs isn't the problem - lack of integration is. If you have a solid MDM strategy and good integration architecture, multiple orgs can actually be cleaner than trying to force everything into one org with complex record types and page layouts."
CPQ questions test whether you understand business processes, not just technical implementation. They want to see if you can translate business requirements into technical architecture.
First, understand the complexity:
Native CPQ vs Custom vs Third-Party:
| Option | Best For | Considerations |
|---|---|---|
| Salesforce CPQ | Standard B2B, moderate complexity | Licensing cost, learning curve, good for most cases |
| Custom Build | Unique business model, simple pricing | Full control, but high maintenance, consider long-term |
| Third-Party (Conga, DealHub) | Specific industry needs, document generation focus | Additional integration point, evaluate features vs Salesforce CPQ |
Architecture for a custom solution (if building from scratch):
Quote Object
│
├─── Quote Line Items (products)
│ │
│ ├─ Product Configuration (options/features)
│ ├─ Price Book Entry (base price)
│ └─ Pricing Rules (discounts/adjustments)
│
├─── Approval Process
│ ├─ Discount approval (if > threshold)
│ ├─ Legal review (if custom terms)
│ └─ Manager approval (if > value limit)
│
└─── Document Generation
├─ PDF Quote
├─ Contract (if won)
└─ Order (send to ERP)
Key architectural components:
"I once built a CPQ for a telecom company. The pricing was insanely complex - different rates by region, volume tiers, contract length, and promotional periods. We used a custom pricing engine with a rules table that could be updated by admins without code changes. The key was making it flexible enough for business users to maintain."
Security architecture questions reveal whether you understand defense-in-depth and compliance requirements. One wrong answer here could cost you the job in regulated industries.
Start with compliance requirements:
Multi-layered security architecture: