Salesforce Heroku Architect

Heroku extends through buildpacks and add-ons rather than custom servers. You choose and combine them, write an app manifest, and package an app so anyone can deploy a copy with one click.

• How buildpacks detect and build an app
• Multiple buildpacks in one app
• Choosing and attaching add-ons
• Add-on plans, limits and lock-in
• app.json and Heroku Buttons
• Reviewing an add-on’s effect on the architecture

You build A deploy-with-one-click app with a custom buildpack mix and chosen add-ons.

Spikes expose every shortcut. You scale out with dynos, choose dyno types, use autoscaling and caching, and find the bottleneck that is not the web tier.

• Horizontal scaling and dyno types
• Autoscaling and its limits
• Concurrency inside a dyno
• Caching at the edge and in the app
• Finding the real bottleneck
• Load testing before the event

You build A load-tested app with a scaling plan for a predicted spike.

The Twelve-Factor method is the design contract Heroku apps follow. You apply it to config, backing services, processes, logs and disposability, and review an app that breaks the rules.

• Codebase, dependencies and configuration
• Backing services as attached resources
• Build, release and run kept separate
• Stateless processes and port binding
• Concurrency and disposability
• Logs as event streams and admin processes
• Reviewing an app against all twelve factors

You build A Twelve-Factor review of an existing app with a list of fixes.

Postgres is the default data store, and plan choice sets its limits. You pick a plan, use followers and forks for read scaling and safe testing, and share results through Dataclips.

• Postgres plan tiers and what separates them
• Connections and connection pooling
• Follower databases for read scaling and failover
• Forks, backups and rollback
• Dataclips for sharing query results
• Maintenance windows and upgrades

You build A Postgres setup with a follower, backup routine and a shared Dataclip.

Kafka carries events between services that must not wait on each other. You learn topics, partitions, consumer groups and retention, and size a Kafka plan for a workload.

• Topics, partitions and ordering
• Producers, consumers and consumer groups
• Retention and replay
• Sizing a Kafka plan
• Security and access on Kafka add-ons
• Monitoring lag and throughput

You build A producer and consumer pair running on Heroku Kafka with lag monitored.

A fast in-memory store removes load from the database. You use Key-Value Store for caches, sessions and job queues, and decide what may be lost and what may not.

• What a key-value store is good at
• Caching patterns and invalidation
• Session storage across dynos
• Job queues and background workers
• Memory limits and eviction policy
• Choosing among Postgres, Kafka and Key-Value Store

You build An app that caches reads and runs a background queue on Key-Value Store.

Splitting an app into services moves complexity into the connections. You build an orchestration layer on Kafka, choose between choreography and orchestration, and keep services decoupled.

• When microservices help and when they hurt
• Choreography against orchestration
• An orchestration layer built on Kafka topics
• Event schemas and versioning
• Failure handling and replay
• Tracing a request across services

You build Three services coordinated through Kafka, with a failure and replay demonstrated.

Regulated customers need proof and isolation. You compare the Common Runtime with Private Spaces, choose between peering and VPN for private networks, and map platform controls to the certifications a client must meet.

• Common Runtime and its exposure
• Private Spaces and network isolation
• VPC peering and VPN connections
• Trusted IP ranges and internal routing
• Certificates, TLS and secrets
• Mapping platform controls to compliance needs

You build A network and security architecture for an app that must reach a private data center.

Enterprise features change what an architecture can promise. You use Private Spaces, Heroku Shield and Enterprise Teams to meet compliance and governance needs, and judge their cost against the risk they remove.

• Private Spaces features and networking choices
• Heroku Shield and regulated data
• Enterprise Teams and access control
• Audit logs and accountability
• Cost against risk for Enterprise features
• Explaining Enterprise value to a sponsor

You build An Enterprise architecture proposal that justifies Shield and Teams for one workload.

Heroku Connect mirrors Salesforce objects into Postgres and back. You design mappings, use external IDs for safe upserts, choose sync modes and read the limits that apply to volume and conflict.

• What Heroku Connect syncs and how
• Mappings and field selection
• External IDs and upserts
• Polling and streaming sync modes
• Conflicts, errors and limits
• Designing a Connect-based architecture

You build A Connect mapping design with external IDs and a plan for sync errors.

Connect is not the only way in. You compare it with direct API calls, external objects through OData, canvas apps and events, and choose the fit for each use case.

• Heroku Connect against direct API calls
• External objects through OData
• Canvas apps inside Salesforce
• Event-driven integration with platform events and Kafka
• Authentication between Heroku and Salesforce
• Choosing an integration for a use case

You build An integration decision record that picks a method for three use cases.

Design an application that must scale, stay private and talk to Salesforce. You choose runtime, data services, network and integration, then defend the architecture against load, cost and compliance questions.

• Reading the requirements and constraints
• Choosing runtime and data services
• Designing network, security and Salesforce integration
• Planning scale and failure
• Presenting and defending the architecture

You build A complete Heroku architecture for one scenario, with scale, security and integration planned.