Advanced 40 min read

Choosing the Right Architecture for Scale

By the end of this lesson, you'll be able to:

Weigh the tools from this module against a given scenario's actual requirements
Avoid reaching for an advanced tool where a simpler one would do
Prepare to apply this decision-making directly in Module 45's capstone project

Prerequisites: "Multi-Tenant Considerations Beyond Governor Limits"

A decision framework, not a checklist

Is data volume the bottleneck, and is the data rarely queried live?
  → Consider a Big Object (Lesson 1)

Is the same rarely-changing data being queried repeatedly?
  → Consider Platform Cache (Lesson 2)

Does another system own the authoritative data, and must it stay live?
  → Consider an external object (Lesson 3)

Is the concern about shared, org-wide resource contention?
  → Design around multi-tenancy directly (Lesson 4), not a specific object type

None of these tools is a default choice — each answers a specific question about a specific bottleneck, exactly Module 43's "reach for a pattern deliberately" principle, applied here to platform-scale decisions instead of code-organization patterns.

Applying the framework to Module 42's banking system, hypothetically

If that project needed to scale far beyond its original nine lessons: seven-year transaction history → Big Object (Lesson 1); a rarely-changing org-wide overdraft limit → Platform Cache (Lesson 2); a genuinely separate, authoritative external ledger system → external object (Lesson 3) instead of Module 42's original callout-based sync, if the ledger truly needed to be queried live rather than just notified. Each choice traces back to a specific bottleneck, not a general instinct to "use the advanced feature."

What Module 45 will require of this thinking

The capstone project ahead will require choosing, from scratch, which of Module 43's code-organization patterns and this module's platform-scale tools actually fit its specific requirements — the same deliberate, requirements-first decision-making this lesson just walked through, now applied without a lesson heading telling you which tool to reach for next.

Exercise

As a comment, using this lesson's decision framework, explain which tool (if any) would fit a scenario where a Salesforce org needs to display a partner company's live inventory counts, which change every few minutes and must never be shown stale.

Show hint

Focus on "must never be shown stale" as the deciding factor.

APEX

Choosing the Right Architecture for Scale Quiz

1. What is this closing lesson's central point about the tools covered across this module?

Each tool solves a specific bottleneck and should be chosen deliberately based on actual requirements, not reached for by default Every enterprise Salesforce org should use all of these tools simultaneously Big Objects should always be preferred over standard objects for any new project These tools are purely theoretical and are never actually used in real orgs

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

This closing lesson ties Lessons 1-4 together into a decision-making framework — matching each tool to the scale and shape of problem it actually solves, echoing Module 43's closing caution against reaching for a pattern just because it exists.

← Multi-Tenant Considerations Beyond Governor Limits Gather Requirements →