Kartikeya Dewal
Hello, I'm Kartikeya Dewal

Lead Engineer

Distributed systems • Go • Kubernetes • Cloud • GitOps

10+ years building backend and platform systems. I spent five of them on the founding engineering team at a Melbourne startup, scaling the platform through multiple phases of growth, and I currently lead engineering work at Publicis Sapient.

View ResumeExplore GitHub

Selected Engineering Work

Problem → Architecture → Key decisions → Results

01

Monolith → Go Microservices

PlayHQ Sports — Melbourne, Sept 2019 – Sept 2024

  • Go
  • TypeScript
  • gRPC
  • Protobuf
  • GraphQL
  • RabbitMQ
  • Kubernetes
  • Helm

Problem

A single backend served every product surface. Teams could not ship independently, and the monolith gave us no language-neutral contract between the Go and TypeScript sides of the codebase.

Architecture

  • ─GraphQL stays the client-facing edge — mutations, resolvers and data loaders written in Go and TypeScript.
  • ─Internal service-to-service calls move to gRPC, with Protobuf as the shared message schema.
  • ─Asynchronous work is modelled as event-driven services on RabbitMQ.
  • ─Each new service ships with its own Kubernetes Helm chart.

Key decisions

  • ◆Protobuf as the single source of truth for message schemas — one contract, generated clients on both languages.
  • ◆Extract services incrementally around real seams instead of a big-bang rewrite, so the monolith keeps serving traffic throughout.
  • ◆Keep Kafka topic provisioning inside the Helm chart, so infrastructure for a service is declared next to the service.

Results

  • ✦Multiple Go services running on gRPC in production, with the monolith progressively carved back.
  • ✦Reduced deployment time by 30% by optimising the end-to-end test suite for faster builds.
  • ✦Cut build tooling licence spend by migrating CI from Drone to GitHub Actions.
02

Real-Time Analytics Pipeline

PlayHQ Sports — data engineering & reporting

  • Kafka
  • Snowflake
  • DBT

Problem

Reporting ran on batch extracts, so product questions were answered against stale data. The ETL was a Node.js Lambda that ran into memory limits as the data grew, so it could not keep pace.

Architecture

  • ─Kafka handles the extract-and-load path, streaming events into Snowflake in near real time.
  • ─DBT models perform the transformations inside the warehouse to complete the ELT workflow.

Key decisions

  • ◆Replace the Lambda ETL with a Kafka extract-and-load path, so ingestion is no longer bounded by the memory of a single function.
  • ◆ELT rather than ETL — land raw events in Snowflake first, then transform them in the warehouse with DBT.
  • ◆Keep the DBT transformations versioned, so schema changes are reviewed like application code.

Results

  • ✦Real-time event streaming into Snowflake replaced the batch reporting path.
  • ✦Recognised for outstanding contributions to the data engineering and reporting solutions.
03

Production Platform From Scratch

Publicis Sapient — Noida, Jun 2025 – Present

  • Terraform
  • Argo CD
  • Kubernetes
  • Go

Problem

A proof-of-concept codebase needed to become production-ready, and there was no infrastructure, no deployment path and no operational baseline to build on.

Architecture

  • ─Cloud infrastructure provisioned from scratch with Terraform.
  • ─Argo CD drives GitOps delivery onto a managed Kubernetes cluster.

Key decisions

  • ◆Infrastructure-as-code from the first commit rather than adopting it after the platform exists.
  • ◆GitOps as the deployment control plane, so the cluster state is always reconcilable from the repository.

Results

  • ✦Migrated the codebase from proof-of-concept to production-ready.
  • ✦Led a team of engineers through code review and iterative delivery, with mentorship across experience levels.
04

Agentic AI Orchestration

Publicis Sapient — Noida, Jun 2025 – Present

  • LangGraph
  • Python
  • GenAI
  • Low-code workflows
  • KEDA

Problem

Generative AI features are easy to prototype as a single prompt and hard to run as a service. The work needed multi-step agents that hold state across a run, can be inspected when they go wrong, and can be operated to the same standard as the rest of the platform.

Architecture

  • ─Agent workflows are modelled as LangGraph graphs — each step is a node, each transition an edge.
  • ─State is carried explicitly through the graph, so every step of a run is visible rather than hidden inside a prompt.
  • ─The agent layer is written in Python and deployed onto the same Kubernetes platform as the rest of the system.
  • ─Agentic workflows are built on a low-code canvas, and the backend triggers them through an API call rather than a human.

Key decisions

  • ◆Model orchestration as an explicit graph rather than an opaque prompt chain, keeping state transitions reviewable.
  • ◆Checkpoint agent state in LangGraph, so runs can be resumed and replayed instead of relying on the model to remember what happened.
  • ◆Treat the agent layer as a service with the same delivery and operational standards as the rest of the platform.
  • ◆Scale agent workloads with KEDA, so pods scale with actual demand instead of running at a fixed size.

Results

  • ✦LangGraph-based agent workflows designed for stateful AI orchestration and taken from proof of concept to production-ready.
  • ✦Agentic workflows created on a low-code canvas and triggered from the backend through an API, so they run as part of the service rather than alongside it.

Engineering Capabilities

Distributed Systems

Service boundaries, contracts and the failure modes between them.

  • Event-driven architecture
  • gRPC & Protobuf
  • Kafka
  • RabbitMQ
  • Data pipelines
  • API design

Backend Engineering

Backend services and the data layer behind them.

  • Go
  • TypeScript / Node.js
  • GraphQL
  • REST
  • PostgreSQL
  • Elasticsearch
  • Neo4j

Platform / Kubernetes

Declarative, reproducible environments across managed Kubernetes and on-premises OpenShift.

  • Kubernetes
  • On-prem OpenShift
  • Helm
  • Docker
  • Kubernetes Operators
  • Operator SDK
  • Tekton
  • GitLab CI/CD
  • RHEL
  • GitOps
  • Argo CD

Cloud & Infrastructure

Infrastructure defined in code and delivered through pipelines.

  • AWS
  • Terraform
  • Infrastructure-as-Code
  • CI/CD
  • GitHub Actions

Observability

Systems you can reason about at 3am.

  • OpenTelemetry
  • Prometheus
  • Grafana
  • Telemetry & instrumentation
  • Performance optimisation
  • On-call support

Agentic AI

Stateful AI orchestration as an engineering problem.

  • LangGraph agent workflows
  • GenAI
  • Python
  • Stateful orchestration
  • Low-code workflow design

How I Work

01

Architecture

Design around real seams in the system. Extract incrementally while the monolith keeps serving traffic, rather than betting everything on a rewrite.

02

Testing

Fast, trustworthy builds are an engineering deliverable. Optimising the end-to-end suite cut deployment time by 30% — test speed is a product of design, not tooling.

03

Reliability

Instrument services end to end with OpenTelemetry, Prometheus and Grafana, and carry the pager for what you build.

04

Automation

If it is not in Terraform, a Helm chart or a pipeline, it is undocumented manual state waiting to break. Infrastructure-as-code and GitOps from the first commit.

05

Technical leadership

Lead engineers across DevOps and application delivery workstreams through code review, design review and mentorship. Interview and grow engineers across experience levels, and contribute to an AI-enabled SDLC training programme delivered to 800+ engineers globally.

Contact

Open to backend and platform engineering work. The fastest way to reach me is email.

kartik@kartikdewal.comLinkedIn