OutSystems Architecture Specialist (O11) flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

OutSystems canvas layers

The four-layer dependency model: End-User (UI), Core (business domains), Foundation (cross-cutting), Library (stateless reuse), plus Service for external APIs. Dependencies point downward only.

End-User module scope

Contains screens, UI logic, and session-bound behavior. It may consume Core, Foundation, and Library elements but must never be referenced by them, keeping business logic reusable.

Core module responsibility

Owns one business domain's entities and rules and exposes public actions. It may reference Foundation and Library but must not reference another domain's Core module directly.

Foundation module purpose

Holds domain-agnostic cross-cutting logic such as integration adapters, utilities, and authentication helpers. It must not own business entities and sits below Core in the canvas.

Library module constraints

Stateless, side-effect-free reusable logic with no references to Core, Foundation, or End-User modules. Safe to share across applications because it carries no domain state.

Entity ownership rule

Exactly one module creates and owns each entity; all other modules access it read-only or through public actions. Prevents duplicate entity definitions and conflicting write logic.

Circular module reference

A producer/consumer loop between modules, blocked by the platform. It signals a layering defect: extract the shared logic into a lower-layer module both can consume.

Module granularity heuristic

Create one Core module per bounded business capability. Splitting by screen or CRUD verb creates chatty dependencies and inflates impact analysis and deployment coordination cost.

Horizontal scaling in OutSystems

Add front-end servers behind the load balancer. Session state lives in the platform database, so servers are stateless and sticky sessions are not required for normal operation.

Front-end vs back-end zones

Front-end servers host End-User modules for user traffic; dedicated back-end servers host Core, Foundation, and integration modules, isolating CPU-bound work from interactive requests.

Read replica rule

Point reporting and read-heavy queries at a dedicated read replica or reporting database, keeping interactive screens off the same connection pool as batch and analytics workloads.

Asynchronous offload threshold

Any screen action expected to run beyond a few seconds should be evaluated for async processing via BPT, timers, or queues, freeing the request thread for user traffic.

Cache invalidation rule

Cache only data read far more often than written that tolerates staleness. Invalidate explicitly on write and never store per-user sensitive data under a shared cache key.

Integration resilience patterns

External calls require timeouts, retries with backoff, and circuit breakers. Chained synchronous calls multiply latency, so aggregate or parallelize when the external API permits.

Screen aggregation rule

A screen should call one aggregate or a small fixed number of server actions. Loops that query the database per iteration create N+1 patterns, the most common scalability defect.

Capacity headroom rule

Plan capacity from measured throughput per server plus 30-50% headroom. Scale out before sustained peak CPU exceeds roughly 70%, so spikes are absorbed without degradation.

Deployment pipeline stages

Develop, Test/QA, Pre-Production, and Production, each a separate deployment zone. Code is promoted as a solution through stages, never re-created manually per environment.

LifeTime role

The platform console for managing applications, deployments, and environment configuration. Environment-specific values belong in platform configuration, not hard-coded in module logic.

Impact analysis before publish

Before publishing, review TrueChange warnings and dependency impact. Breaking a public action signature forces every consumer module to be republished and retested.

Technical debt baseline

Module complexity and integration indicators plus TrueChange warnings form the health baseline. Schedule refactoring as warnings accumulate, before incidents force unplanned work.

Semantic versioning rule

Breaking changes to public elements require a major version plus consumer coordination; additive, backward-compatible changes take a minor version. Applied to modules and solutions.

Pipeline quality gate

A stage passes only when automated regression and smoke tests are green and TrueChange is clean. Gates block promotion, catching defects before they reach production.

Cross-environment performance comparison

Compare platform performance monitoring and logs across stages. Divergence between environments points to configuration differences; consistent slowness points to code regressions.

Reproducible rollback

Keep the previous tagged solution version deployable in every stage, so rollback is a redeploy of a known version rather than an emergency code fix under pressure.

Architect canvas ownership

The architect owns layer placement, module boundaries, entity ownership, and naming, and publishes the canvas as the reference before development begins.

Developer module autonomy

A developer owns internal logic, local variables, and private actions within an assigned module. Changing a public element signature requires architect review.

Public element as contract

Anything consumed by another team - public actions, entities, exposed APIs - is a contract. Changes need the owning team's agreement, unlike private module internals.

Team topology alignment

Team structure mirrors module ownership: one team per set of Core modules, with Foundation and Library owned by a shared platform or services team.

Architecture review gates

Canvas conformance checked at design, public-element changes at code review, and dependency violations blocked in the pipeline instead of being discovered in production.

Non-functional standards ownership

The architect defines caching policy, async thresholds, integration patterns, naming, and error handling; developers apply them and document any approved deviation as an exception.

Cross-domain data escalation

When a team needs another domain's data, it uses an agreed Core public action or a Foundation service. Direct references between teams' Core modules are forbidden.

Architect governance artifacts

The architect maintains the canvas diagram, module inventory with owners, public-element catalog, and the technical-debt backlog prioritized jointly with product management.