Redis powers many critical functions for BBC Online's biggest pages, including acting as a content cache, metadata store, and queue. It allows BBC to build a flexible platform of nanoservices that maximize reuse, speed, reliability and scalability. Redis' performance enables BBC to handle large audiences reliably and build new features faster, benefiting both developers and audiences.

1. How Redis Powers BBC Online’s Biggest Pages
Jonny Glancy
BBC Sport

2. • Background
• What
• Why
• How
• Redis
• Action
• Summary
2

3. 3
Background

4. 4

5. 5

6. 6
Pattern

7. • Responsible for a single, non-trivial, business-understandable task
• Smaller than a microservice, larger than a function
• Likely to call other nanoservices, to offer rich functionality
• The ideal sized package to release (or MVT) in a CD environment
• All the benefits of microservices, without the infrastructure… right?
Nanoservices
7

8. 8
Why Nanoservices?

9. 9

10. 10

11. 11
Dev Ops
UX Test

12. 12
Benefits of Nanoservices

13. • Model means that teams can focus on building product differentiators – not re-
creating platform infrastructure
• Templates encapsulate logic or presentation that can be shared and reused
• Reduced testing overhead with clear tools & processes
• Managed CI deployment pipelines take nanoservice templates from laptop to
live
• ‘Deploy and forget’ - Centralised DevOps process embedded within platform
team
Benefits for our Teams
13

14. • Pages that load fast and update automatically
• Faster development allows features to be released sooner with greater
functionality
• Greater quality of delivery
• Platform is able to handle our biggest audiences, reliably
Benefits for our Audience
14

15. • We’ve seen new teams spawn,
producing entire websites in a fraction
of the time that the organisation used
to see
• Ready to go… The editorial team were
still trying to work out their strategy!
CBBC Newsround
15

16. 16
Great… Lets Go Deeper!

17. 17
Scorecard
Title Carousel
Summary Live Stream
Innings
Table

18. 18
Live Page
Header Body
Carousel Title
Media
Data
Media API
Sport
Event Data
Sport Data
API
Content
Data
Content
API
Summary
Innings
Table
Live
Stream
Stream
Data
Stream API
Scorecard

19. 19

20. 20
Redis

21. 21

22. • For us, it is much more than just a key-value store
• Multiple data types, LUA scripting, Pub/Sub
• Automates common administrative tasks (failed nodes, server optimisation)
• Multiple options available (different memory and network sizes)
• Can grow with sharding and/or replication
Elasticache
22

23. • Poor utilisation of resource
• We’re often scaling vertically to satisfy capacity needs
• Using 100% CPU of one core whilst 15 other cores are sat idle
• Slow to receive engine version updates
• Can’t extend with modules
• £££££££££
Elasticache…
23

24. 24
Developer
Data (APIs, etc.)
Audience
Nanoservice
Store
Nanoservice
Platform
Content
Cache
Metadata
Store
Queues

25. • Every output from every run of every
nanoservice is stored
• Cheap, simple, ephemeral
• Flexible eviction policies, LRU in our
case
• Maximises reuse, speed, reliability,
and scalability
Redis: Content Cache
25

26. 26
Keys

27. 27
Memory

28. • Metadata about every request, and its
‘tree’, is stored in Redis
• If the data changes, the metadata
informs us what nanoservices to rerun
• The ‘relationship’ is stored both ways:
A>B and B>A
• Lua can help make atomic
Redis: Metadata Store
28
Scorecard
Sport Event
Data
Sport Data
API
Innings Table

29. • Operations involving state mutations
are critical
• Loss of relationships, both up and
down the tree, can cause “stuck” state
• Using LUA vs Redis Transactions
means we avoid clashes and can
perform operations across multiple
keys
Redis: Metadata Store
29
Scorecard
Sport Event
Data
Sport Data
API
Innings Table

30. • Redis, as a queue, is extraordinarily
fast (<5 ms end-to-end journey)
• It’s the only solution fast enough for
this architecture
• We comfortably do >10k messages
per second
Redis: Queues
30

31. • Doesn’t really work with replication, SPOF!
• Lossy (due to consumer failure)
• Can be offset with by using an in-progress-queue and something to analyse it
• Harder to scale
Redis: Queues
31

32. 32

33. 33
Action

34. 34
T1 T2 SD

35. 35
RendererFetcher API
Caches
Queues
Service
Data
T1
T2
SD

36. 36
Summary

37. • Redis has mega performance potential, not just in caching content, but as a
control and communication layer
• This can let you build fast and flexible serverless-like platforms that allow your
organisation to move faster
• The nanoservice pattern is an interesting way to design for serverless, and can
maximise the potential of continuous delivery, reusability, and flexibility
• Without Redis, we wouldn’t be able to do what we’re doing as a product and a
greater organisation
Summary
37

38. Thank you!