start blog
This commit is contained in:
parent
ab877ac96d
commit
91d6445b4f
1 changed files with 63 additions and 0 deletions
63
posts/stumbling-accross-the-strategy-design-pattern.md
Normal file
63
posts/stumbling-accross-the-strategy-design-pattern.md
Normal file
|
|
@ -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.
|
||||
Loading…
Add table
Reference in a new issue