Scalable architecture design: stateless tiers, data volume and asynchronous work
Scalable architecture design tests whether your module split and runtime choices still hold when concurrent users, data volume and node count grow.
Design for a stateless tier
OutSystems front-ends keep no authoritative state in memory: session variables live in the session database and are re-read on each request. That is precisely what lets you add front-end servers behind a load balancer. So the scalable rule is: keep session variables small and rare, prefer screen or client variables plus re-queried data, and never park a large result set in session "for speed".
Push work to the right place
- Query only what the screen shows: filters on indexed attributes, Max Records, pagination.
- Move heavy or long-running work into Timers or BPT processes that write results to a summary entity the screen reads cheaply.
- Avoid entity actions inside a cycle (the N+1 pattern); one aggregate with a join beats N lookups.
- Index the attributes you filter and sort on - the platform does not guess them for you.
- Split Platform Server roles (controller, front-end, deployment controller, scheduler) across machines when the load profile demands it, instead of only adding front-ends.
Worked example
A manager dashboard takes 9 seconds with 40 concurrent users. The screen aggregate returns 180,000 order rows and sums them in a For Each. Reasoning: the cost is data transfer plus client-side computation, and extra front-ends cannot fix a query that returns everything. Fix: a Timer aggregates totals nightly into an OrderSummary entity, OrderDate and AccountId are indexed, the aggregate filters by period, and the screen renders a paginated table.
Traps
- Caching in memory or session and assuming it survives a scale-out.
- Adding front-end nodes to a query-bound problem.
- Leaving a slow integration inside the screen request, consuming the request thread; wrap it and set a timeout.