SA on Performance Architecture: Designing Systems That Stay Fast Under Load
Performance is a design property, not a tuning exercise. Five components of SA’s performance framework, benchmark targets for every page type, and four anti-patterns eliminated at design review before a single query is written.
Why Speed Is a Design Property, Not a Tuning Exercise
Performance is commonly treated as a problem to solve after a system is built and users are complaining. SA treats performance as a design property that must be engineered into the system from the beginning. Every major performance problem in a software system has an architectural root cause. These root causes are cheaper to address at design time than at optimisation time.
Five Components Considered at Design Time
Query pattern analysis
Before finalising the data model, SA maps every major query the system will run: what the dashboard displays, what search filters on, what lists sort by. Every query is evaluated at current scale, 10x scale, and 100x scale. Data model changes that make expensive queries cheap are made before building begins.
Denormalisation planning
SA identifies every metric, count, or aggregation displayed frequently in the UI. Each is pre-calculated and stored as a denormalised field, updated by workflows when data changes. Dashboard metrics, list counts, status summaries — all stored, not calculated on render.
Caching strategy
For data that changes infrequently but is read frequently (reference data, configuration, plan limits), SA caches in a settings record. For external API responses that rarely change (exchange rates, public data), cache with a timestamp and refresh on a schedule.
Pagination design
Every list is paginated from design — not added later. SA designs data source, page size (20 items), navigation controls, and reset-to-page-one behaviour before any repeating group is placed. The page with 100,000 records performs identically to the page with 100.
Background processing
Long-running operations — batch imports, report generation, bulk updates — are designed as asynchronous background processes from the start. The user initiates, sees processing feedback, and is notified on completion. This prevents UI blocking and allows operations of arbitrary length.
Targets We Design To and Measure Against
| Page Type | SA Target | How Achieved |
|---|---|---|
| Dashboard (main) | < 2 seconds | All metrics denormalised; zero live count queries |
| List pages | < 3 seconds | 20 items/page; search constraints; single-level fields |
| Detail pages | < 2 seconds | Single record load; related data via direct field reference |
| Search results | < 1.5s after input stops | Constraints only; debounce; no :filtered by |
| Initial app load | < 4 seconds | CDN delivery; minimal blocking JS; optimised images |
| API responses | < 500ms | Pre-optimised privacy rules; denormalised response fields |
Never Reach Production
NEVER
: Search for Tasks :filtered by status = Active
ALWAYS
: Search for Tasks [status = Active] (server-side)
// Anti-pattern 2: Live aggregation on render
NEVER
: Text = Search for Tasks [workspace=X]:count
ALWAYS
: Text = Workspace’s open_task_count (pre-calculated)
// Anti-pattern 3: Deep relational chain in RG cell
NEVER
: Current cell’s Task’s Project’s Workspace’s name
ALWAYS
: Current cell’s Task’s workspace_name (denormalised)
// Anti-pattern 4: Unlimited repeating group
NEVER
: Items per page = All items
ALWAYS
: Items per page = 20 with navigation controls
Work With SA — Simple Automation Solutions
Pakistan’s leading no-code systems architecture practice. We design tech systems before we build them.
