NNEXUSby VIM · data engineeringLet's talk ↗

Independent engineering portfolio / Presented for 73 Strings

7373 StringsSenior Data Engineer · London

01 — FIND THE SIGNAL

NEXUS.

One reliable thread from source to valuation.

Fewer duplicate client pipelines. Earlier detection of broken data. A traceable history behind every valuation input.

Follow the thread ↓

Built at Lifepal · presented for 73 Strings

The platform behind the string.

I’m Firman Insan Muhammad. You can call me VIM. At Lifepal, I led a financial-services data platform with PostgreSQL change capture, Debezium and Kafka Connect, Azure Databricks, Delta Lake, medallion models and production quality gates. These patterns help 73 Strings turn changing source data into traceable, timely inputs for monitoring and valuation.

Inspect working code ↗Pull up a chair →

Lifepal outcomes come from my CV. This independent 73 Strings case study uses synthetic events to show the mechanics.

02 / ROLE FITRelevant experience, clearly scoped

A close stack match.
A clear business use.

Reusable ingestion, source-position replay and publication checks help 73 Strings reduce client-specific pipeline work, surface broken data before it reaches monitoring, and preserve the history behind a valuation. The reference below tests the CDC edge cases.

Current capture path

Debezium + Kafka Connect

At Lifepal I handled ordering, deletes, replay and schema change from PostgreSQL sources. The reference keeps capture separate from the publish contract so transport can change.

Lifepal · direct overlap
Processing & modelling

Azure Databricks + Delta

I built Bronze, Silver and Gold layers with PySpark, dbt and dimensional models, and tuned a nightly batch from six hours to 90 minutes.

Lifepal · direct overlap
Client delivery

Snowflake + dbt

At Deloitte I delivered Snowflake and dbt warehouses for banking and insurance clients. A tenant-scoped delivery contract and reconciliation record give each destination the same release boundary.

Deloitte · direct overlap
Operating model

GitHub + CI/CD

Tests, review, Terraform-defined deployments, runbooks and incidents were part of my platform work. This repository has a real GitHub Actions test workflow.

Lifepal · direct overlap
HOW IT HELPS 73 STRINGS

73 Extract→73 Monitor→73 Value

One traceable data path supports extraction, monitoring and valuation. Explore 73 Intelligence ↗
01 / EXTRACT

Onboard feeds once

Reviewed metadata maps source fields and keys into a shared loader. A new client feed gets a reviewed configuration instead of another pipeline copy.

02 / MONITOR

Catch breaks before clients do

Freshness, row-level checks and reconciliation expose missing or invalid updates, with a source position and reason to investigate.

03 / VALUE

Explain every number

Versioned history links a published valuation input to its source event, accepted change and tenant, so analysts can review how it changed.

03 / THE SYSTEMCapture → contract → decision

Architecture overview

Make every string traceable.

This source-to-client path shows how the Lifepal platform patterns support 73 Strings: preserve change order, reuse feed definitions, hold bad rows, and publish client-scoped data with a traceable history.

Interactive system mapExplore the source-to-client pathChoose any block to inspect its code or contract.Show mapHide map
73 STRINGS / DATA ENGINEERING

One source of truth, several client destinations.

A moving pulse follows the publish path

01 / SOURCE

Capture what changed

Private-market data arrives with different shapes and clocks.

02 / INGEST

Keep order, allow change

Decouple capture from the dataset contract.

03 / PROCESS

Governed lakehouse

Azure Databricks joins both cadences on Delta.

04 / TRUST

Publish what checks

A bad row waits; good rows can move.

05 / DELIVER

Serve the right client

One contract, approved destinations, tenant scope.

The stack comes from the 73 Strings job description and my CV. The Python reference runs with synthetic events; the Delta SQL and destination interfaces show the corresponding implementation boundaries.

INSPECT THE STRING

Source excerpt

Open full source ↗Independent portfolio reference
04 / THE INVARIANTSEquations that change operating behavior

The math behind trust.

These checks make replay safe, account for each received row and protect client-specific outputs. The reported outcome below belongs to Lifepal; the equations describe this synthetic reference.

FROM MY LIFEPAL CV24h → <5m

Reported reporting delay after the platform work. For 73 Strings, stage-by-stage source-to-client timestamps reveal where freshness is lost.

01CDC order & replaySource log position · deletes · recovery3 equations

current(k) = arg maxe:key(e)=k LSN(e)

Order per tenant and entity. Arrival time is not a safe substitute.

load(load(T, B), B) = load(T, B)

Reprocessing the same batch leaves visible state unchanged; the local test checks this.

LSNdelete > LSNupsert ⇒ visible(k) = ∅

A newer tombstone wins over an older update, even after an incident replay.

02Quality & reconciliationRow quarantine · release gate · source counts3 equations

Nreceived = Napplied + Nreplayed + Nquarantined

A reconciliation failure should stop publication and create an actionable incident.

B = Bvalid ∪ Bquarantine

Good rows can progress while invalid rows retain a reason and source context.

publish(r) ⇔ schema(r) ∧ key(r) ∧ value(r) ∧ tenant(r)

Checks must pass before a record becomes visible to a client destination.

03History & tenant scopeSCD2 · valuation lineage · client isolation3 equations

valid_to(vi) = valid_from(vi+1)

An SCD2 update closes the previous version at the next accepted source position.

deliver(t) = { r ∈ published : tenant(r) = t }

Every output path binds to an explicit client tenant before delivery.

F = now − max(event_timevisible)

Measure the age of what clients can query, not just the capture job.

04Cost & capacityThroughput · incidents · cloud spend2 equations

Bt+1 = max(0, Bt + λt − μt)

If incoming changes outpace processing, freshness falls even when jobs succeed.

1 − $11K / $19K ≈ 42%

My CV reports Lifepal spend near $11K per month against a $19K forecast.

05 / WORKING CODERun it, replay it, inspect it

Synthetic CDC reference

The edge cases are the demo.

The repository contains a pure-Python CDC engine and tests for out-of-order events, replay, deletes, row quarantine, tenant isolation and SCD2 intervals. The browser trace illustrates those tested paths; it does not connect to a client system.

Choose a source event

DECISION TRACE130.00 visible
Loading tested scenario…

Arrival order changes; source order decides the visible valuation.

examples/cdc_reference.pyPYTHON
Loading source excerpt…
Runnable synthetic portfolio referenceOpen full source ↗
LOCAL TESTS8 behavior checks

Run python3 -m unittest discover -s examples -p 'test_*.py' -v. GitHub Actions runs the same suite on pushes and pull requests.

View CI runs ↗
06 / PULL UP A CHAIRA conversation for the actual role

Let's talk about the hard parts.

Five practical questions about how these patterns help 73 Strings keep data current, trustworthy and safe for each client.

01 / CAPTURE

What if the CDC capture method changes?

VIM: A versioned envelope carries tenant, entity key, source position, operation, schema version and payload. That lets the capture transport change while replay tests and the publication contract stay stable. I ran Debezium CDC into Azure Databricks at Lifepal; the reference demonstrates the boundary with synthetic events.

02 / REUSE

How do copied client pipelines become components?

VIM: Reviewed feed metadata holds field mapping, keys, load mode, schema and checks. A shared loader then handles each new feed consistently, reducing one-off pipeline copies. I used this pattern at Lifepal with Python and PySpark; the repo includes a feed manifest and adapter.

03 / TRUST

How do good rows publish while bad rows wait?

VIM: Per-row validation preserves a reason and source position for each exception. Reconciliation then checks that every input is applied, replayed or quarantined before client-visible publication. At Lifepal I worked with contracts and 500+ checks; the synthetic test shows an invalid valuation cannot block an unrelated valid row.

04 / CLIENTS

How do Snowflake, SQL Server and Databricks stay in sync?

VIM: One curated, tenant-scoped product and a common destination contract give all three sinks the same source version, reconciliation total and freshness signal. I built Snowflake/dbt warehouses for financial clients and Databricks/Delta models at Lifepal. The repository shows the delivery boundary; each production sink still needs its platform adapter.

05 / OPERATIONS

Who owns the failure at 2 a.m.?

VIM: Source position, failed contract, quarantined rows, last published version and affected tenant identify the impact and recovery point. I have owned GitHub CI/CD, Terraform, runbooks and incident fixes. This repository runs behavior tests in GitHub Actions so the recovery rules remain inspectable.

Production outcomes and career experience come from my CV and cover letter. This independent role-focused reference runs on synthetic events. Learn more about 73 Strings’ valuation and monitoring platform ↗.

Continue the conversation

Let's connect the right strings.

Happy to walk through how reusable ingestion, CDC recovery and client-scoped delivery support 73 Strings’ extraction, monitoring and valuation work. London based; right to work in the UK without sponsorship.

Email VIM ↗Connect on LinkedIn ↗