Software & Data Engineer

Srikanth

AWS Certified · Python · SQL · Kafka · Flink · PostgreSQL

AWS Certified Data Engineer. Two years of payments & platform engineering at redBus, an MS from Wilmington University — now rebuilding my streaming CDC capstone in public: 41 tests, CI, and a Databricks-on-AWS migration underway.

I'm actively seeking Software Engineering and Data Engineering roles in the US — and documenting what I build along the way.

View projects GitHub LinkedIn
About

From production engineering at redBus to streaming data platforms.

I'm a software & data engineer based in Rockville, Maryland, with an MS in Information Systems and Technology (Information Assurance concentration) from Wilmington University and nearly 2 years of engineering experience at redBus, India's largest online bus ticketing platform.

At redBus I grew from an intern into a full-time engineer on the payments side — building payment reconciliation workflows across gateways, migrating UPI checkout to intent flows with Google Pay and PhonePe, routing transactions through the highest-success-rate channels, and working on the initial LLM integration behind redBus's in-app AI travel assistant (since relaunched as “RAY”).

For my Master's capstone I built a streaming Change Data Capture platform — Debezium and Kafka capturing row-level changes from Postgres, Apache Flink handling deduplication and schema evolution, and Delta Lake tables with data-quality gates and Grafana monitoring.

I'm open to Software Engineering and Data Engineering roles where I can build reliable systems end to end — from ingestion and validation to analytics and deployment.

Experience

redBus — intern to full-time engineer.

Building data platforms in public now — after growing intern-to-engineer at India's largest online bus ticketing platform.

Data Engineer — Independent Projects
May 2025 – Present · Self-Employed · Rockville, MD
Rebuilding my capstone CDC pipeline in public (postgres-cdc-lakehouse) — 41 pytest tests against real Delta tables, ruff lint, GitHub Actions CI on every push. Migrating the storage layer to Databricks on AWS: S3, IAM cross-account roles, Unity Catalog external locations. Shipped DriveLingo AI to production (Render + Neon) and publish weekly technical posts documenting the builds.
Software Engineer
Feb 2022 – Jul 2023 · Bengaluru
Built payment reconciliation workflows in Python across payment and refund gateways — matching internal transaction records against gateway settlements to catch mismatches on a platform serving millions. Migrated UPI checkout from collect to intent flows and integrated Google Pay and PhonePe; built dynamic gateway switching (UPI apps, BHIM, direct bank rails), BIN-based card routing, and the redBus wallet. Worked on the initial LLM integration behind redBus's AI travel assistant (now “RAY”), and load-tested services ahead of peak-season traffic.
Software Engineering Intern
Aug 2021 – Jan 2022 · Bengaluru
Debugged customer escalations — double-debit and double-booking incidents traced to missing idempotency at the order layer — and supported production testing ahead of releases. Wrote technical documentation mapping architecture and data flows. Converted to full-time after the internship.
Skills

What I work with — and what I'm learning next.

Grouped honestly: what I have shipped with, and what I am learning next.

Programming & Querying

PythonSQLC

Databases & Modeling

PostgreSQLRelational DesignData ModelingIndexesConstraintsData Validation

Backend & APIs

FastAPIREST APIsSQLAlchemyPydanticEnv Config

Data Engineering Concepts

KafkaFlinkDebezium (CDC)Delta LakeGreat ExpectationsETL / ELTDeduplicationRaw vs Processed

Tools

DockerAirflowdbtGrafanaGitGitHubPostman / Swagger

Learning Next

Currently learning
AWS (certified)Databricks cert prepPySparkCloud deploymentSnowflake / BigQuery
Projects

From streaming CDC to local commerce — one engineering approach.

A streaming CDC platform built as my Master’s capstone, a traffic-sign intelligence system that now reads signs with OCR, a vendor-analytics platform in progress, and where it all started — an RFID system in my B.Tech.

01 / flagship · master’s capstone

Streaming CDC Platform

Grade A · rebuilding in public
Change Data Capture · Streaming · Data Quality Enforcement

A near-real-time pipeline that keeps an analytics layer in sync with a production Postgres database without polling the source. Debezium and Kafka capture row-level changes from the write-ahead log; Apache Flink processes the stream — deduplication, late-arriving events, schema evolution — and data merges into Delta Lake tables via upserts. Data-quality gates quarantine bad records instead of breaking the pipeline.

What I built
  • Log-based CDC with Debezium + Kafka (no source polling)
  • Flink stream processing: dedup, late events, schema evolution
  • Delta Lake tables with upsert / merge logic
  • Great Expectations quality gates that quarantine bad records
  • Grafana dashboard: lag, throughput, data freshness
  • Python transaction simulator (orders, users, payments) as the source app
Rebuild in public — live now
  • Public repo: 41 pytest tests against real Delta tables (not mocks), ruff lint, GitHub Actions CI on every push
  • Databricks-on-AWS migration underway — S3, IAM cross-account roles, Unity Catalog external locations
PythonPostgreSQLDebeziumKafkaFlinkDelta LakeGreat ExpectationsGrafanaDockerpytestGitHub Actions
View rebuild repo
// pipeline
01Postgres WALrow-level changes
02Debezium + Kafkalog-based CDC stream
03Flinkdedup · late events · schema
04Delta Lakeupserts + quality gates
05Grafanalag · throughput · freshness
02 / computer vision pipeline

DriveLingo AI

Deployed · live on Render + Neon
Traffic Sign Intelligence · Event-Driven Backend Pipeline

A system that turns what a camera sees on the road — traffic signs in any language — into something a driver can understand and act on: what the sign says, in their language, and why it matters. Imagine driving in Japan and a sign flashes past: 止まれ. DriveLingo sees it, reads it with OCR, understands it (“Stop” · regulatory), translates it, and explains why it matters — while raw events stay separate from processed records so everything can be reprocessed with better models.

What I built
  • FastAPI backend with GET / POST endpoints
  • PostgreSQL + SQLAlchemy models
  • Pydantic schema validation
  • 404 + 409 duplicate handling
  • Unique index + IntegrityError rollback
  • .env-based config & raw ingestion table
  • OCR worker extracting sign text from images (confidence scores)
  • Deployed: FastAPI on Render, Postgres on Neon, Alembic-managed schema
What I learned

Duplicate protection can't live only in the API — the database has to enforce it too, with constraints and unique indexes as the final safety layer. Separating raw ingestion from processed records is what keeps a pipeline reprocessable instead of locked to one model.

Roadmap
  • Language detection + translation
  • AI-generated safety explanations
  • Driver alerts + analytics (OCR confidence, sign frequency by region)
PythonFastAPIPostgreSQLSQLAlchemyPydanticAlembicOCRGit
View repo
// pipeline
01traffic_sign_eventsraw ingestion table
02validatePydantic + duplicate checks
03PostgreSQLconstraints + unique index
04OCRsign text extracted
05translate + alertplanned
03 / local commerce

LocalLoop

In progress · building
Local Vendor Intelligence · Event-Driven Analytics Pipeline

An event-driven data platform that captures anonymous NFC / QR interactions between households and local service vendors — plumbers, electricians, AC technicians, tiffin services — then validates, transforms, and analyzes them into vendor-retention, service-category, and locality-level metrics. Customer data stays private; vendors see only aggregated, anonymous insights.

Scope
  • Ingest raw NFC / QR tap & save events
  • Validate & deduplicate interaction events
  • Separate raw, cleaned & analytics-ready layers
  • Model vendors, localities, events & metrics in PostgreSQL
  • Build vendor-retention & repeat-business analytics
  • Serve aggregated metrics via FastAPI
Privacy-first by design

Customer identities are never exposed — vendors see only aggregated metrics like profile taps, saves, repeat-interaction rate, and locality trends. Questions it answers: which categories and localities see the most repeat activity, what share of saves lead to repeat service, and which vendors grow month over month.

PythonSQLPostgreSQLFastAPISQLAlchemyPandasdbtAirflowDockerGit
Repo coming soon
// pipeline
01NFC / QR tapraw interaction events
02validate + dedupclean tap & save events
03PostgreSQLoperational storage
04ETL / transformdbt · analytics model
05metrics + APIretention · locality · FastAPI
04 / where it started · b.tech final year

RFID Campus Exit Tracking

Completed · team project
Embedded Systems · RFID · Presence Tracking

My B.Tech final-year team project at JNTU Hyderabad: RFID tags embedded in student ID cards triggered an Arduino-based reader module at campus gates on exit, logging events and enabling alerts. Programmed the reader logic and event handling in C. In hindsight, it was my first presence-tracking system — the same instinct behind LocalLoop’s NFC interactions today.

CArduinoRFIDEmbedded Systems
// flow
01RFID tagembedded in student ID
02Arduino readergate module · C logic
03exit eventlogged + alert triggered
Learning journey

Building in public, one small lesson at a time.

A running log of what I'm learning as I build. Small lessons, but they're what turn tutorials into real understanding.

Lesson 01

Raw vs. processed data

In DriveLingo AI, raw traffic sign events are stored before any OCR or translation runs, so they can be reprocessed later with a better model, checked for errors, or reused for analytics.

Raw = what the system received. Processed = what the system understood.
Lesson 02

Git feature branches

Instead of committing every change to main, I built the ingestion layer on its own branch. It made me understand why teams keep stable code separate from work in progress.

main = stable version. feature branch = safe workspace for new changes.
Lesson 03

Duplicate protection, two layers

I added logic so the same traffic sign record can't be inserted repeatedly — and learned that this can't live only in the API. The database has to enforce it too.

App validation is useful. Database constraints are the final safety layer.
Lesson 04

Environment variables

Instead of hardcoding the database URL in Python, I moved it into a .env file. Cleaner code, and much easier to move between local development and future deployment.

Code stays reusable. Environment-specific settings live outside the code.
Lesson 05

Request-based vs. event-based

A request-based system waits for an action and returns a response. An event-based system stores what happened so different services can process it later — which is where DriveLingo is heading with camera and dashcam input.

The long-term goal isn't manual upload — it's a pipeline that handles traffic sign events.
This week

Progress check

The capstone rebuild is public: 41 pytest tests running against real Delta tables, ruff lint, and GitHub Actions CI on every push. Databricks-on-AWS migration underway — S3 buckets, IAM cross-account roles, Unity Catalog external locations. DriveLingo is deployed and live on Render + Neon.

Next focus: rebuilding the CDC capstone on AWS in public, Databricks certification, and finishing LocalLoop.
Resume

The short version, on one page.

Software & Data Engineer · AWS Certified · Python · SQL · Kafka

Data engineer with two years at redBus (India's largest online bus ticketing platform) building payment reconciliation workflows and LLM features in Python for a platform serving millions. AWS Certified Data Engineer – Associate; Databricks certification in progress. Now rebuilding my capstone in public — a streaming CDC pipeline hardened with a 41-test pytest suite and CI, with a Databricks-on-AWS migration underway. I find why data is wrong, fix it, and prevent recurrence.

Download résumé (PDF)
Skills
Languages: Python, SQL, C · Streaming & Data: Kafka, Flink, Debezium, Delta Lake, Airflow, dbt, Great Expectations · Backend: FastAPI, SQLAlchemy, Pydantic, PostgreSQL, REST · Tools: Docker, Git, pytest, GitHub Actions, Grafana, Prometheus
Currently learning
AWS Certified Data Engineer – Associate (2026) · Databricks Data Engineer Associate (scheduled)
Experience
redBus — Software Engineer (Feb 2022 – Jul 2023) · Software Engineering Intern (Aug 2021 – Jan 2022), Bengaluru, India
Education
MS, Information Systems and Technology (Information Assurance) — Wilmington University, May 2025 · B.Tech, ECE — JNTU Hyderabad, 2018–2022
Contact
srikanth.mcu@gmail.com · +1 (252) 284-5365 · Rockville, MD · www.linkedin.com/in/srikanth-mcu · github.com/srikanthbattula9
Contact

Let's talk data engineering.

I'm open to Software Engineering and Data Engineering roles — and always happy to talk pipelines, streaming systems, or AI integration.

srikanth.mcu@gmail.com +1 (252) 284-5365 LinkedIn GitHub