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
ProblemFiles 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
OutcomeEach 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
ProblemMore 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
OutcomeOne 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
ProblemMore 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
ProblemBatch 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
OutcomeProcessing 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
ProblemAnalytics 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
ProblemEvent 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
OutcomeEvery 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
ProblemDocument 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
OutcomeTerabytes 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