It is no longer enough to know a single platform for enterprise implementations, including managed platforms like Salesforce. Even though Salesforce does handle so much by itself, for a high-quality project, engineers need to know how to deal with distributed systems.

For years, I worked within the "walled garden" of Salesforce. It's a powerful place where Governor Limits keep your code safe, Platform Events handle your messaging, and Sharing Rules manage your security. You focus on in-platform efficiency and business demands rather than technical constraints. But as implementations grow and involve multiple third-party systems, platform-only knowledge becomes insufficient. You have to learn how to build the engine instead of just driving the car.

When you leave a managed-platform-only mindset, you become the "Governor," and Salesforce becomes just another system in your landscape. This is the story of why you should extend your horizon and place Salesforce where it makes sense without overloading its responsibility.

Here is what Salesforce handles for you, what you need to handle yourself — and how you build your own enterprise level distributed system.

What Salesforce Handles for You, and Where You Need to Take Over

Load Balancing

Salesforce handles load balancing within strict platform limits, so engineers mostly don't need to think about it in terms of platform outages, and these mechanisms are not exposed to developers. More specifically, this handling relies on hard caps per transaction (enforcement boundaries) but still requires strong solution design per tenant to ensure the stability of the integrations and implementations. This still requires distributed-system thinking.

Authorization

Salesforce offers different types of built-in authorization methods such as JWT, OAuth 2.0, and basic auth (discouraged due to data leak risk!). When the integration is inbound to Salesforce, auth is handled via an External Client Connected App (the previous version, called Connected Apps, is still operational if it was created before the rollout, but new ones can't be created as of the current platform version, unless enabled through Salesforce Support). For outbound integrations, it is handled via Named Credentials.

Caching

Salesforce does have the platform cache partition definition to store cached data (not out of the box — via Apex code) without requiring any third-party systems like Redis. However, when the standard REST API isn't covered by the feature, it still requires manual handling — either via an ApexRest wrapper or a third-party system.

Event Management

Event management is handled using Platform Events or CDC, and Salesforce events can be listened to using the standard API capabilities. The trouble comes when Salesforce needs to listen to third-party system events. One important detail: Salesforce does not ensure preservation or recovery of published events outside the retention window, so the listening system must register and act on the event itself.

Idempotency

Platform Events and CDC follow an at-least-once delivery model. This means consumers must implement idempotent processing and duplicate detection via the idempotency-key header field (Reference), as well as re-requesting missed events via replay_id (Reference) within the retention window. Inbound requests still require the originating system to generate a UUID and attach it to the request header, and Salesforce to preserve and process them.

Backup/Disaster Recovery

Salesforce maintains a platform-level backup to support disaster recovery options, including paid Backup & Recover capabilities. However, a recovery strategy should not rely only on Salesforce-managed mechanisms. Depending on the recovery path, access may require Salesforce Support intervention, may not be fully controlled by the org admin, and may not guarantee restoration to the exact moment before the incident. Enterprises still need a client-owned backup, archiving, and disaster-recovery strategy.

What you should handle yourself?

Enterprise Level Load Balancing and Optimization

Even though Salesforce handles the platform-wide load, eventually it denies new long-running requests. The platform still completes the already-running concurrent processes within Salesforce's concurrent-request limit (for APIs, it is 20 concurrent requests, applied to any request running longer than 20 seconds — Reference). Especially for systems working directly with consumers, which are mostly under high load, you need external buffering, throttling, or queuing before data enters Salesforce to preserve the data intake. Load balancing here is slightly different from a traditional distributed system, due to Salesforce's org-level isolation per customer; instead, you distribute the requests with a throttle to protect the Salesforce backend and route certain requests (failed acknowledgments, etc.) to the message broker for retry or delayed processing by the system external to Salesforce.

Guaranteed Delivery

A Message Broker is an important addition to the system, because managed platforms should not be the first system exposed to unpredictable traffic. The message broker ensures that when Salesforce can't acknowledge a request, message broker will capture it and prepare it for retry to absorb Salesforce unavailability. In addition, message queues can support the system's throttling process to avoid "long-running concurrent processes" hitting the wall. One thing to remember: a message broker is not a miracle worker that ensures the system runs seamlessly for all real-time processes. When the message queue receives the request, it will process it at the next available processing window.

Caching

Caching for the standard REST API is a great way to ease the pressure on the platform limits. It's common for certain static information (such as configurations or catalogs) to be accessed frequently via API for every interaction, which is far from how scalable architectures are built. However, because Salesforce isn't handling this, it is sometimes disregarded. Personally, I look at this aspect as highly circumstantial. Caching may provide limited value for low-traffic integrations, but becomes critical at high interaction volumes. It is also recommended to estimate the cost of the caching system versus the consumed API units to decide if it is worth implementing — still, it is quite an important concept to know and consider.

Event Listener

An event listener for external events is mandatory to build at the middleware level, because when it comes to listening to the outside world, the Salesforce API layer is slightly opinionated. There might be workarounds on certain systems via a webhook approach to avoid adding a new layer/system, using the Salesforce REST API (such as SAP event mesh — but even with a broker in between, it is REST-first integration); yet you lose the concept of pub/sub by replicating a REST-based workflow to mimic the outcome. For true event subscription, an intermediary system must be integrated as an event broker. The event broker will register the event and route it to the Salesforce destination.

Inbound Requests Idempotency

Salesforce depends on a unique UUID generated by external systems to handle inbound request idempotency. The strategy can be either registering the idempotency key as an external id and keeping it indefinitely (which still has a slight risk of duplicates, when the system entropy is low for UUID generation), or using a cache table — either via third-party tools like Redis or an internal custom object — to make the idempotency key shorter-lived, which could make the design live longer with less friction. Both options have their own merits and trade-offs, which require careful assessment. Indefinitely living keys allow you to use the standard Salesforce unique external id approach and require less customization, while a short-lived key may require third-party involvement or simply introducing another layer of validation.

Archiving/Backup

Archiving and backup, as mentioned above, require a client-defined strategy, which also depends heavily on the available tech stack. Salesforce does have the capability to store large data sets and high volumes, especially via Data Cloud — yet it requires a "middle-man" to carry the data from source to destination. Still, to avoid a "single point of failure" risk, a complementary location is highly recommended. One example would be Amazon S3 buckets, considering their cost implications and native Data Cloud connection, to still make archived data available for segmentation and reporting, while a dedicated bucket stores org snapshots for disaster recovery without involving Salesforce at all.

Beyond Salesforce, when any managed platform becomes the slice of the pie rather than the entire pie in your projects, strong consistency becomes expensive.

If your architectural design assumes immediate, synchronous coverage across five different platforms, your system will constantly fail. As engineers, we must learn to embrace operational/eventual consistency. We must design our systems around the realities of network latency, building robust retry mechanisms, DLQs (Dead Letter Queues), error handling, and delayed synchronization.

Stop just driving the car. Lift the hood, understand the limits of the ecosystem, and start building the broader distributed engine.