In this session, we’ll explore the various approaches to caching data in an OutSystems application—from the basic concepts of caching, to situations when you should or shouldn’t cache data. We’ll also discuss how to use the built-in cache mechanism in OutSystems, including how it works, how to implement it, and some considerations for best practices. For mobile apps and reactive web applications, we’ll cover caching data client-side using IndexedDB, as well as additional server-side caching resources.

1. Caching in OutSystems
A Tale of Gains without Pain
Helena Lameiro
Senior Engineer @ NTT Data
2022-02-23
1

2. … another presentation
on performance !!!
Agenda
Caching concepts
When and why to use Cache?
1
OutSystems Built-in Cache
How it works, slightly under the hood
Cache invalidation
Best practices and considerations
Other Server-Side Caching Resources
Application Cache component
Distributed Caching
Caching Client-Side
Mobile and Reactive
IndexedDB
2
3
4 2

3. 1
Caching concepts
3

4. 4
So, What Is Cache All About?
Temporary store fetched data from
server in fast memory or local resource
Improve performance
Better user experience
Data displayed to user faster
Data are available faster on next
requests

5. 5
When To Cache Data?
● Elements fetched from databases or
external systems with low mutability
Lot of requests = Same Response
● Impact end-user experience
● Overload on system resources
● Elements with controlled scope
parameters (user session)
● Data consistency !
● Data changes frequently.
● Caching mechanism is hard to maintain
● System Architecture already has
several cached components on external
systems or DB
(Caching mess)
Don’t Cache!
Cache!

6. 2
OutSystems Built-in Cache
6

7. 7
“Cache in Minutes” Property - Where To Find It?
Server Logic:
● Server Actions
● Aggregates
● SQL Nodes
Traditional Web:
● Web Blocks
(without submit or ajax submit)
On previous OutSystems versions:
● Screens
● Consumed SOAP methods

8. 8
OutSystems’ Built-In Cache – How It Works (I)
RAM-based
● All front-end servers
● One stored instance per server
● Always first miss
Factories with more than one front-end
● First miss on each front-end
Cache expires
● “Cache in Minutes” property
Caching instance is defined by:
● Front-end
● Input Parameters
● Consumer modules and reference type
(weak or strong)
● Tenant in multi-tenant app
Not available on personal environments (no RabbitMQ)

9. 9
OutSystems’ Built-In Cache – How It Works (II)
1st Request
Application
Request
Cache
Missed
Data source
Fetched
Data
Cache
Back
Further Requests
Application
Request
Cached
Data
Cache Cached

10. 10
OutSystems’ Built-In Cache – How It Works (III)
Cached Requests
Application
Request
Cache
Cached
Data
Cached
Cache expired
Application
Request
Cache
Data source
Expired
Fetched
Data
Cache
Back

11. 11
OutSystems’ Built-In Cache – Parameters
Caching Actions is only possible if input parameters are not a binary
or complex type.

12. 12
OutSystems’ Built-In Cache – Parameters
Caching Actions is only possible if input parameters are not a binary
or complex type.

13. 13
OutSystems’ Built-In Cache – How It Works (III)
Server vs. Service Actions
Flow with Server Actions – Strong dependency
● Action logic is executed in the context of each consumer module.
● Cached instances may differ by consumer module.
Flow with a Service Actions – Weak dependency
● Cache is defined at the consumer module that holds the service
action.
● All its consumers have access to previous cached data (per FE).

14. 14
Flow with Server Actions – Strong dependency
Same Parameters - Different consumers
Next
Request
Data source
Fetched
Data
Cache
Back
Cache
Missed
End User Module 1
Application
Request
Entry
Data source
Fetched
Data
Cache
Back
Cache
Missed
End User Module 2
Application
Request
Entry

15. 15
Flow with Service Action – Weak dependency
Same Parameters - Different consumers
End User Module 1
Application
Request
End User Module 2
Application
Request
Cached
Data
Next
Request
Data source
Fetched
Data
Cache
Back
Cache
Missed
Entry
Cache Cached
Entry

16. 16
OutSystems’ Built-In Cache – Site Properties
● Loaded by the server.
● Hold data that has to be available across the module.
● Cached for faster access.
● Should be updated manually in Service Center.
● Isolate site properties in separate module ([ModuleName]_Config).
Updating site properties invalidates the cache of the module and requires the
properties to be reloaded from the database.

17. 17
Some common use cases
Bootstraps, data migration bulk operation with
repetition of data fetched

18. 18
Some common use cases
Data fetched from external resources used very
frequently

19. 19
Some common use cases
Generic actions commonly used on most
applications

20. 20
Some common use cases
Heavy calculation logic or request that is
commonly requested

21. 21
OutSystems’ Built-In Cache – Cache Invalidation (I)
“There are only two hard things in
Computer Science:
Cache Invalidation and Naming Things.”
Phil Karlton

22. 22
OutSystems’ Built-In Cache – Cache Invalidation (I)
Cache invalidation is hard to control:
● All or nothing
● Performance expensive
(forcing evaluation on next usage)
● Possible problems with logic
(outdated values)

23. 23
OutSystems’ Built-In Cache – How Cache Can Be “Cleaned”
Cache in minutes property control
● Cache expired
Logic
● New request forcing change on input
parameter value (context or dummy).
● System actions:
○ EspaceInvalidateCache
○ TenantInvalidateCache
System and Infrastructure
● RAM memory overrun
● Front-end server reboots
● Module is published
● Service Center – redeploy published version

24. 24
OutSystems’ Built-In Cache – How Cache Can Be “Cleaned”
Cache in minutes property control
● Cache expired
Logic
● New request forcing change on input
parameter value (context or dummy).
● System actions:
○ EspaceInvalidateCache
○ TenantInvalidateCache
System and Infrastructure
● RAM memory overrun
● Front-end server reboots
● Module is published
● Service Center – redeploy published version
performance impact during the first
access of an application

25. 25
OutSystems’ Built-In Cache – Cache Invalidation in
OutSystem 11 (III)
Cache Invalidation Service
● Underlying mechanism – publish/subscribe via RabbitMQ
● Notifies each of the front-end servers that cached values are
evicted.
● When cache invalidation occurs for a module or a tenant:
1. All applications watching for changes on these
elements are notified.
2. Flag their local copies as dirty.
3. Set to reevaluation on new requests.

26. 26
OutSystems’ Built-In Cache –
Implementation Best Practices (I)
Avoid caching isolated
Aggregates or Queries
Add _cached suffix to server
action with cache
● Description should indicate that action is cached, its
purpose, and for how long.
● Identify Parameters with specific cache context.

27. 27
OutSystems’ Built-In Cache –
Implementation Best Practices (II)
Use a dummy cache invalidation
parameter to control Cache
Avoid cached actions without
input parameters

28. 28
OutSystems’ Built-In Cache –
Implementation Best Practices (III)
Define the way you want cache to occur Configure cache to your use case
● Short vs. Long Cache
● Warming cache or Background
Loading (via timer)
● Performance Bottlenecks

29. 29
OutSystems’ Built-In Cache –
Some considerations
RAM memory is also shared to run your application logic
● Don’t over cache
● Cache in minutes should be the least possible for you business case
● Check for Performance Bottlenecks
● Be gentle on cache invalidation
●

30. 3
Other Server-Side Caching
Resources
30

31. 31
Distributed Cache

32. 32
Distributed Cache - when to use?
● +3 Front End Servers
● public-facing Web apps with “static”
data.
● Shared data with some mutability
● Need 100% control over cache
● Need to share state between Servers
without using Database or Session
● 1 or 2 Front End Servers
● Low amount of traffic
● No performance issues
● Trying to replace entirely built-in
mechanism!
Don’t use it!
Can use it!

33. 33
Distributed Cache - patterns
Cache aside
Background Data Push

34. 3
Caching Client - Side
34

35. 35
Mobile Application – Client-Side
● Use a Specific Sync Unit.
● Client variable or local entity attribute with cache
timeout and last sync.
● Avoid first miss with warm-up.
● Sync local data if cache evicted
○ update cache timeout and last sync
● Mechanism of cache invalidation to ensure data
consistency.
Optimize Data For Your Use Cases Using Hot Cache
Save cached data on local storage with cache synchronization
Be careful with sensitive data storage.

36. What about
Caching Client-Side
in Reactive Web?
36

37. 37
Mobile and Reactive Web Applications – Client Side (II)
● Basic data types
● Key Value structure
● Add a last sync timestamp
● Verify last sync against cache in minutes value
● Avoid first miss
● Sync data if cache evicted
● Ensure a cache invalidation mechanism
Web Storage API
Client Variables or Web Storage API handling
Be careful with sensitive data storage

38. 38
Reactive Web Application – Cache Client-Side
● Mimetize local storage entities.
● Storage cached data in IndexedDB in browser – check
availability.
● DB instance must be created first.
● Data created asynchronously.
● Data can be indexed.
Indexed DB
Be careful with sensitive data storage.

39. 39
IndexedDB - Can I Use

40. 40
Cache in Client Side - general consideration
● Avoid first miss - warming strategy
● Sync data if cache evicted (set a condition for eviction)
● Add a last sync timestamp
● Ensure a cache invalidation mechanism on destroy / on app resume (only
on entry module)
● Take into account:
○ Load of data being cached
○ Type of data being cached
○ Logic for retrieve data from cache
Be careful with sensitive data storage

41. 41
It’s DEMO
then...

42. 42
Share your story
● Have you ever used Cache before?
● What were your Use Cases?
● Queries, Screens, WB, Never
● What about client side?
● local storage
● other approaches?
● Advantages and issues that you had with
caching

43. 43
THANK YOU !!!!
Helena Lameiro
Senior Engineer @ everis, an NTT Data company
Linked in