Skip to content

Instantly share code, notes, and snippets.

* Future State Architecture: Incept and engineer on our next generation platform applications
* KR 1: Retire 5 legacy content platform systems
* KR 2: Consolidate to a single API that stores all content (GraphQL Content Service)
*** What we did:
* GP migration
* Looking at Apollo alternative (GQL Hive)
* API authentication (in progress)
* CDP Deprecation (kafka)
* EKS Optimization (tsugu/content service)
* Non-prod: increased intance type to c5.xlarge
* running tests on non-prod (ba)
* we are hitting search
* we are hitting identifiers
* tracking cpu/memory
* blackbird (caching)
* possibly thinking about increasing the instance type
* based on results increase instance type
* choose a brand (BA) to migrate to GP
* P95/P99 Response Time should be close to what we had in Departure
Thursday
Look Forward
------------------
Objective
Evolve the Publishing Platform to continue transitioning to North Star Architecture with GraphQL
KR
KR 1: Add mutations to Content Service
KR 2: Additional subgraphs into Federation (hreflang, user service)
KR 3: Additional clients calling Federation (native apps, encore, copilot)
Core Id Recap
Recommendation
Just to move departures services to GP and keep related infra (kafka clusters) in current AWS account (cndigital).
Why?
* Moving off of logbus is going to take a long. For reference, ripping out logbus from org service took about 6 months.
* Logbus does not work with Confluent and/or MSK, more specifically, Logbus was customized in a way that can't connect to Confluent.
* Tons of business logic in Logbus
Things to do to enable GP EKS to talk to Kafka clusters in cndigital:
* Create private links from each region to be able to reach the Kafka cluster (deployed in us-east-1).

Keybase proof

I hereby claim:

  • I am gmedina on github.
  • I am gmedina (https://keybase.io/gmedina) on keybase.
  • I have a public key ASBwX4UDFgOFEyIj8w7UC9AUbcSmUi6vi-IfJnfNU7bzJgo

To claim this, I am signing this object: