Designing a Scheduling Content Management System (CMS)
Problem statement
Consider the following problem statement:
I have a webpage which, among other things, contains a number of paid promotion slots which may be booked by merchants in advance.
The terms we've agreed to require the contents to be promoted must start being shown at some time, then should be taken down sometime later (likely so that the next merchant placement can go up).
Note that merchants will likely book placements a few weeks ahead of time, but the system must also accommodate last-minute changes.
Potential approach #1
There are a few ways that you could tackle this problem, and each will present their own trade offs.
Of course, the first simpler approach is to have a regular Content Management System for the page and task someone with putting the content live on the page at the appropriate times, effectively changing the live page as agreed, in real time.
This might work as a one-off approach, but it really gets old fast. More often than not promotions will start at midnight, local time. Even if someone is tasked to do this only once a week, it's an ineffective use of anyone's time, besides encroaching on someone's own time while outside of work.
Besides, any potential mistakes that would be obvious to catch if seen on the page (such as a wrong link or a poorly cropped lower quality image) will likely slip through until they reach the live page on the day of the actual promotion.
Potential approach #2
Another approach to be considered is to have some discrete process or code that is scheduled to take action at the specific time the promotion is configured to go up. This could be something like a serverless function, which pulls the up-to-date contents from a private stash, then publishes the appropriate contents to the live page.
On one hand, this does resolve the problem of having someone awake at midnight. On the other hand, it doesn't solve the problem of catching mistakes before they go live on the page. Additionally, it introduces some new problems.
In case there are issues with the scheduled code -- such as if a bad revision was pushed and the code fails to finish the page update -- these won't be caught until the next day during office hours. Having someone awake to monitor that the transition occurs smoothly each time also defeats the purpose of automating.
Proposed approach
This brings us to the approach #3, which is a perspective shift on the whole problem we're trying to solve.
Consider the contents of the page “P” and some content configuration “C”.
In a traditional CMS, the contents of the page are a direct function of the supplied configuration. We can represent this as:
P = f(C)
In the two prior approaches, we tackle the problem of updating the page “P” at the correct times by attempting to change “C” exactly at the correct time.
An alternative approach, though, that I claim to be more robust, is to consider the timestamp “t” to be an input parameter for the logic that renders the page.
P = f(C, t)
On the live page, no surprises, we simply supply the current timestamp to the page rendering logic.
P = f(C, t=now)
Now we can preview some point-in-time in the future, such as the second the promotions are supposed to go up, by supplying the “t” corresponding to that time. Likewise, we can supply any time “t” in the past and see how the page was shown to users.
For this approach to work, there are a few requirements:
(i) The implementation of “f” (the page's own rendering logic) must not take in a “now” timestamp from any other source. The time “t” must be a parameter completely injected as a value when the page is being rendered. It will just so happen to match the “real” time when we want to render the live page.
(ii) The configuration “C” will need to include all the information so that the future (and previous) contents of the page can be fully constructed. This means that the links, images and promotional information must be known ahead of the page going live, instead of being dynamically obtained in the time the promotion goes up (which would bring back issues similar to approach #2).
Conclusion
The proposed approach was implemented for a high-traffic Shopping page with great success. It cut down the number of live site incidents, which were close to weekly when approach #1 was being employed.
By allowing point-in-time previewing of the page at future dates and key times, it gave the editorial team in charge of the page the tools required to double-check their own work and ensure all the operations went smoothly for the major part of a year.
I think the major appeal of this approach is that there are no “moving parts” and no processes that must take place exactly at required times. The whole page rendering logic “f” already runs for every user visit at every page view, so it remains constantly in use, unlike code scheduled to run at a particular time.
Of course, the gains in team dynamics are enormous since the whole configuration process can be done weeks ahead of time, during office hours. An additional member of the editorial team can double-check another's work by pointing the preview to a particular future point-in-time, thus further cutting down on configuration issues before they reach the live page.
Next Opportunities
One possible room for improvement is to allow for A/B testing so as to gauge the user's interest on different content (in the case of non-paid placements).
Currently, it's possible to set up different page content, at different times or at different placements. However, without true randomized user testing, one could never rule out the hypothesis that one content performed better than another -- not due to its higher quality and appeal to the userbase, but merely because of random effects, or maybe because it was more prominently placed on the page at that time.
Randomized user assignment to different treatment groups which get shown different content can truly isolate intrinsic content quality from seasonal effects, page positioning effects, and background random noise to power well-informed decision making based on sufficient evidence.