Welcome to "This Is My Architecture."
I'm Lana from AWS.
And today we're talking to Zach from Arc Publishing at Washington Post.
- Welcome. - Thank you.
Awesome having you here.
And would you mind telling us a little bit more about
this rendering and content management system
that you've built at Washington Post?
Yeah.
So, I'll be talking about our web rendering platform.
Arc Publishing is a company at the Washington Post
that builds software for the Post and then also builds software
and provides it to other media companies around the world.
So what we're gonna be talking about today is the request flow
for how public users...
generate requests
to this platform to view HTML web pages,
like the WashingtonPost.com.
So this is somebody who comes to the web page
and wants to view Washington Post for today's issue, let's say.
Exactly. Yep.
So when they hit our architecture, they're gonna hit an origin.
This origin runs on ECS.
The origin is gonna handle the traffic routing through the architecture.
So, there'll be a request flow
that will access static resources like JavaScript and CSS.
And then they'll also be a request flow
that makes requests for pre-rendered HTML content.
And this makes pages load faster, I'm assuming.
Exactly.
So caching is paramount in the architecture.
Public users are gonna hit a CDN first.
If cache is missed there, it's gonna hit our origin proxy.
If origin proxy cache is missed, it's gonna ask for S3.
And then if S3 is a miss, it's gonna make a request
to the site rendering code that's hosted in Lambda.
So we're doing some dynamic rendering at this point.
Exactly.
So about 5% to 10% of the time
cache is missed through that whole request flow,
and at that time, a Lambda is invocated to render a web page for the user.
That sounds great.
So I'm seeing here that we're using an ECS cluster again.
So what kind of workloads are we running here?
So, the second ECS cluster has to do with gaining access to content.
So a request is made
during the web page rendering process to a proxy,
and that proxy is going to make a secondary request
over the Internet to content management or to content.
For most cases, it's going to be
the content management system provided by Arc.
In other cases, it might be APIs or other CMS systems
that the Washington Post or our customers utilize
to put content into their web pages for the end users.
What kind of content are you managing here?
Most commonly, it's stories, images, galleries and videos.
But there's also use cases where there are unique APIs,
like sports APIs or weather or internal APIs as well.
Got it.
So we have this payload that we just pulled in from the CMS system
or content management system.
So where does it go from here?
So, the requests for content will go back and render into the Lambda.
But before that, we'll do one thing,
we'll store it into ElastiCache,
the raw JSON object and set a TTL on that object.
- So time-to-live. - Yep.
- Okay. - Time-to-live.
So the next request that comes in accessing that same piece of content,
most likely will get it from ElastiCache
and not from the Internet making the request flow faster
and more reliable for the end user.
So I'm seeing that now we have two types of rendered content,
so how do you make a determination of what to store in ElastiCache
versus put it in S3 bucket for pre-rendered content?
Yeah, that decision is really the developer's decision
who's doing development on our platform.
Pre-rendering is an option that we make available
for higher availability use cases or periods of time
where you want to guarantee that web content or cache
is warm and available to end users.
Okay.
And how are you using DynamoDB in this scenario?
Yeah, so we have two additional use cases.
The first is a newsroom user.
So we have a product called Page Builder Admin
that allows the user to create a web template.
That web template is gonna control what pieces
of information are on a page, how that page should look,
and is made available
during the dynamic rendering process from Lambda.
And then the second use case is a developer.
The developer is going to build their web rendering code
inside of JavaScript and make a deployment to Lambda.
A deployment is essentially creating a new version of Lambda,
and then the developer makes that version
live through a promotion process that
where the ELB directs which version of the Lambda is live.
That's great.
So this kind of helps us with high availability
and make sure that you can roll back any changes if something goes wrong.
Yep, high availability and then also blue green deployment options
and pre-testing options.
Awesome.
I love the fact that you're using Lambda in multiple functions.
So you're serving your internal users and your developers
and also fetching some of the content
that might not be rendered and doing it dynamically on the fly.
Well, Zach, thank you so much for coming down today
and telling us a little bit more about rendering
and content management at Washington Post.
And thank you for watching "This Is My Architecture."