Data Engineer · GCP & AWS

Designing petabyte-scale data architectures.

I build petabyte-scale data platforms across AWS and GCP, with streaming, CDC and metadata-driven pipelines that turn raw data into clean, trusted datasets. That makes data ready for AI engineers and data scientists to train and run models on, as well as for the analysts and dashboards that run the business.

lineage · systems I've built7 pipelines · GCP + AWS
SourcesIngestionWarehouse / Lake
Petabyte
scale architectures on AWS and GCP
3,000+
tables kept in sync by my CDC architecture
30+
sources on one metadata framework
TBs
streamed from Kafka & MongoDB into Delta
BigQueryDataflowPub/SubCloud ComposerRedshiftAWS GlueEMRAWS DMSStep FunctionsKafkaDelta LakeAirflowdbtSnowflakePySparkMongoDB

fct_architectures

Systems I've designed and shipped

Seven production pipelines across GCP and AWS. Each shows the problem, how data flows end to end, and what changed afterwards.

Streaming file ingestion into BigQuery

GCP
event-drivenno manual loads
Problem

Files landing in Cloud Storage had to wait for scheduled batch loads or manual triggers before anyone could query them in BigQuery.

Flow
File lands in GCS→GCS notification→Pub/Sub→Dataflow streaming job→BigQuery
Outcome

Each file is processed and queryable in BigQuery as soon as it lands, with no polling, schedules or manual steps in between.

Cloud StoragePub/SubDataflowApache BeamBigQuery

Petabyte-scale metadata-driven ingestion platform

GCP · AWS
30+ sourcespetabyte-scale
Problem

More than 30 source systems each needed their own ingestion pipeline, which made every new source slow to add and hard to keep consistent.

Flow
30+ sources→metadata config→Cloud Composer DAGs→GCS landing→BigQuery
Outcome

One framework ingests every source at petabyte scale. Adding a source means adding its metadata, and Airflow runs all loads with the same scheduling, retries and alerting. The same petabyte-scale design also runs on AWS.

BigQueryCloud ComposerAirflowCloud StorageAWSPython

Metadata-driven MySQL to Redshift warehouse load

AWS
500+ tablesT-1 refresh35% faster
Problem

More than 500 MySQL tables had to reach Redshift every day for reporting. Hand-writing a pipeline per table would not scale.

Flow
MySQL · 500+ tables→table config→Glue bulk & incremental→S3→Redshift
Outcome
  • All 500+ tables refresh on a T-1 basis from one reusable framework.
  • New tables onboard through config templates, with no custom code.
  • Optimised load patterns and SQL cut runtime by 35%.
MySQLAWS GlueS3RedshiftSQL

Event-driven medallion lakehouse

AWS
Bronze · Silver · Goldauto-recovery
Problem

Batch jobs ran on fixed schedules whether or not new data had arrived, and failed runs needed someone to step in and restart them.

Flow
Data lands in S3→S3 event→Step Functions→Bronze→Silver→Gold
Outcome

Processing starts when data arrives. Step Functions handles retries, alerting and failure recovery between layers, which cut manual intervention.

S3Step FunctionsAWS GlueLambdaMedallion architecture

CDC Delta Lake for 18+ databases

AWS
3,000+ tables synced18+ sourcesMSSQL & MySQLchange data capture
Problem

Analytics needed every insert, update and delete from 18+ MSSQL and MySQL databases in the lake, with full history and PII handled under GDPR.

Flow
MSSQL · MySQL→AWS DMS CDC→S3 raw→EMR / Glue merge→Delta Lake
Outcome
  • One metadata-driven framework keeps 3,000+ tables from 18+ sources in sync in Delta Lake, orchestrated by Airflow.
  • PII hashing, retention policies and schema governance built in.
  • Shipped with Docker and Jenkins CI/CD.
AWS DMSAirflowEMRAWS GlueDelta LakeDockerJenkins

Kafka topics to Delta Lake

AWS
TBs ingestedone Delta table per topicbulk + incremental
Problem

Event data lived in Kafka topics that analysts couldn't query, and it needed both its full history and the ongoing stream in the lake.

Flow
Kafka topics→bulk backfill + incremental→S3→Delta table per topic
Outcome

Every topic lands as its own queryable Delta table. A bulk load brought in the history and incremental loads keep each table current, across terabytes of event data.

KafkaS3Delta LakeAWS

MongoDB to Delta Lake

AWS
TBs ingestedbulk + incremental
Problem

Document data in MongoDB sat outside the lake, so it couldn't be analysed alongside the relational and event data.

Flow
MongoDB collections→bulk + incremental extract→S3→Delta tables
Outcome

Terabytes of MongoDB data now sit in Delta tables on S3, kept current incrementally and queryable next to every other source in the lake.

MongoDBS3Delta LakeAWS

dim_skills

Skills

Everything I use to build, run and govern data platforms.

Languages

SQL (advanced)PythonPySparkSpark SQL

Google Cloud

BigQueryDataflowPub/SubCloud ComposerCloud Storage

AWS

S3GlueRedshiftDMSEMRAthenaStep FunctionsLambdaSQSEC2

Warehouses & storage

SnowflakeRedshiftBigQueryDelta LakePostgreSQLMySQLMSSQLMongoDB

Orchestration & streaming

Apache Airflow (MWAA, Composer)Step FunctionsKafkaPub/SubCDC

Modelling

dbtKimball star schemasSCDData martsMedallion architectureMetadata-driven frameworks

Quality & governance

Automated testsReconciliationSchema-change detectionMonitoring & alertingGDPRPII hashingRetention policiesLineage

DevOps & BI

GitJenkins CI/CDDockerPower BITableauQuickSight

dim_education

Education

A grounding in data analytics and information technology.

Queen Mary University of London logo

Master's in Data Analytics

Queen Mary University of London

London, UK

Delhi Technological University logo

Bachelor's in Information Technology

Delhi Technological University

New Delhi, India

mart_contact

Need data that scales? Let's talk.

Open to Data Engineer roles on AWS or GCP: large-scale ingestion, streaming, CDC, lakehouses and data platforms for AI.