CUSTOMER DATA PLATFORM
From disconnected sources to useful customer data.
Professional engineering work connecting source integrations, backend services and analytical storage. This overview focuses on my contributions without exposing client data or proprietary implementation details.
More than moving records.
Customer information rarely arrives in a single, consistent shape. Different sources bring different structures and integration requirements. A useful platform needs to connect those sources while giving downstream services and analytics a coherent view of the data.
This work brought together application engineering and data engineering: designing services and models while also thinking about ingestion, storage and access patterns.
Where I contributed.
- Backend services and AWS infrastructure for the data platform.
- Source connectors, configuration and relational modeling in PostgreSQL.
- Python and AWS Lambda routing, ingestion workflows and performance work.
- Analytical storage workflows using Amazon S3, Apache Iceberg and Athena.
Two workloads, different needs.
Operational and analytical data
The platform used PostgreSQL on RDS for operational data and an S3-based lakehouse with Iceberg and Athena for analytical workloads. Working across both made the relationship between application behavior, data modeling and query patterns central to the engineering work.
The interesting questions extended beyond individual tools: how source configuration should be represented, where service responsibilities should sit, and how data would be consumed after ingestion.
The engineering perspective.
This project is a useful example of the kind of work I enjoy: connecting product needs to services, infrastructure and data flows, then staying involved in the implementation details.
I'm happy to discuss the general engineering lessons and tradeoffs. Client-specific data, internal diagrams and proprietary implementation details are not part of this public portfolio.
Let's talk about data-platform engineering ↗