From 91d6445b4fa72ba14a4d4235a16f7ed63086d86f Mon Sep 17 00:00:00 2001 From: thomasabishop Date: Sun, 4 Jan 2026 17:19:45 +0000 Subject: [PATCH] start blog --- ...ing-accross-the-strategy-design-pattern.md | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 posts/stumbling-accross-the-strategy-design-pattern.md diff --git a/posts/stumbling-accross-the-strategy-design-pattern.md b/posts/stumbling-accross-the-strategy-design-pattern.md new file mode 100644 index 0000000..f172d96 --- /dev/null +++ b/posts/stumbling-accross-the-strategy-design-pattern.md @@ -0,0 +1,63 @@ +--- +title: "Stumbling accross the strategy design pattern" +slug: /stumbling-accross-the-strategy-design-pattern/ +date: 2026-01-04 +tags: ["typescript", "python"] +--- + +In this post I am going to talk about an effective design pattern I came accross +in the course of my work. Please note that I will obscure any senstive +operational details and focus only the technical aspects. + +A lot of my work consists in integrating the different applications that our +stakeholders use to manage the content libraries of streaming services. When a +user updates a catalog item in one application (let's call it 'Alpha'), this +should update related records in another application (let's call it 'Omega'). + +On the surface, this is a fairly trivial workflow managed via a serverless AWS +pipeline. When Alpha is updated, an event is added to an SQS queue which +triggers an associated Lambda which is subscribed to the queue. The Lambda +parses the event data, transforms it into the data structure expected by Omega, +and sends it on. + +The data contained in the SQS event body is usually minimal. It specifies the +type of event that has occurred in Alpha, along with the record category and ID +of the affected record. For example: + +```json +{ + "status": "created", + "category": "show", + "id": "SHOW-0001" +} +``` + +So we use the ID to send a further API request to Alpha to get the full record +information and we use this to populate the data that is sent on to Omega. + +The complexity arises from the fact that there are about eight different +category types, each with subtly different transformational rules ('mappings') +and, for certain categories, the record will be a 'child' to another 'parent' +record, where some of the mappings of the child have to be inherited from the +parent. In the latter case, additional API requests must be made to (a) check +that the parent exists and (b) if it exists, retrieve that data and append to +the child. + +In addition, the properties mapped from Alpha to Omega are not always a simple +one-to-one correspondence. Sometimes the data must first be pre-processed and +translated into a form that Omega will understand, whereas other times it can +simply be passed on unaltered. Furthermore, not every Alpha category has a +corresponding category in Omega. There is at leas one scenario where one Alpha +category can correspond to two Omega categories. + +Finally, there is an additional contextual complexity in that the mappings that +we implementing are often subject to change as the business is still working out +the optimal data-flow betweeen the two applications. So, we often need to make +revisions on the fly. + +It should be clear from the preceding account that we have a domain where there +is a significant degree of commonality and repetition alongside more contingent +factors. I needed to create a solution that ... whilst being abstracted enough +to... + +My solution works as follows.