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