Nishtha Gupta

cloud and backend engineer · college park, maryland

I design event-driven systems on AWS

Every service choice answers a specific access pattern.

Seeking Summer 2027 software internships

  • 20–50×

    faster p99 verification — 80–150ms down to 2–10ms via a Redis cache-aside layer

  • 2 hrs → 15 min

    regression suite runtime after automating 100+ tests at TIAA

  • 100+ hrs

    engineering time recovered per sprint for a 5-engineer delivery group

climatewatch — ingest to query

Data flows from Kinesis into DynamoDB for key-value lookups and into S3 for columnar scans via Athena, with EventBridge orchestrating. Kinesis stream buffering EventBridge orchestration DynamoDB key-value lookup S3 columnar store Athena scan on read
Each managed service answers one access pattern — stream buffering, key-value lookup, object storage, columnar analytics — which keeps ingestion, storage, and analytical workloads independently operable.

about

Software engineer with 2+ years building backend systems and cloud infrastructure, now doing an M.Eng. in Cloud Engineering at the University of Maryland. Python, Java, REST APIs, AWS, Terraform, Kubernetes, CI/CD, observability, and both relational and NoSQL stores.

I led backend development for customer-facing products, and a good share of my production experience is the unglamorous half of distributed systems: tracing participant data across MuleSoft APIs, MDM, Snowflake, and Salesforce to isolate where records diverged. That work is why I instrument observability while building rather than after something breaks.

projects

Systems, and the decisions behind them

Lottery Verification Platform

Infrastructure and Networking Lead · 2026

A verification service where I owned the network and infrastructure layer, then kept extending it after the team build ended.

  • Designed AWS networking and container infrastructure across a multi-AZ VPC, ALB, ECS Fargate, and port-scoped security groups, with the full stack provisioned and torn down via 10 modular Terraform components.
  • Decoupled claim processing from the verification response path using SQS with a dead-letter queue (maxReceiveCount=3, 14-day retention), so verification stays available independently of claims-service failures.
  • Reduced p99 verification latency 20–50× — 80–150ms down to 2–10ms — with an ElastiCache Redis cache-aside layer, while excluding WINNER outcomes from caching to prevent stale claim state across agents.
  • Benchmarked with a purpose-built script and custom CloudWatch metrics (CacheHit, CacheMiss, VerificationLatency) before and after Redis, validating the cache across both cold and warm request paths.
  • Evaluated database-per-service decomposition and retained a shared RDS instance by design, with SQS payloads carrying enough context for the claims service to operate independently of the verification data tier.
AWSECS FargateVPCSQSElastiCacheTerraform
architecture — Redis cache-aside, SQS with DLQ, shared Postgres
A verification request reaches the verification service through an application load balancer. The service reads through an ElastiCache Redis cache and falls back to RDS PostgreSQL. Winner events are published to an SQS queue consumed by the claims service; messages that fail three times move to a dead-letter queue. ALB multi-AZ verification-service ECS Fargate ElastiCache cache-aside RDS Postgres shared, by design SQS claims queue claims ECS Fargate dead-letter 14-day retention WINNER event after 3 retries
Verification reads through Redis and falls back to Postgres — except WINNER outcomes, which always read from Postgres so a cached result can never show stale claim state to another agent. Winner events go to SQS, so claim processing can fail without taking verification down with it; three retries, then the dead-letter queue holds the message for 14 days. Both services share one RDS instance, chosen over database-per-service because the SQS payload already carries enough context for claims to run independently. The whole stack stands up and tears down through 10 Terraform modules.
source ↗

ClimateWatch

2026

A streaming climate-data pipeline that ingests, persists, and queries records through event-driven workflows.

  • Orchestrated the pipeline across Kinesis, DynamoDB, S3, Athena, and EventBridge.
  • Designed service access patterns around stream buffering, key-value lookup, object storage, and columnar analytics — mapping each workload to Kinesis, DynamoDB, S3, and Athena respectively.
  • Separated ingestion, storage, and analytical workloads through event-driven components, so each can be operated and scaled independently.
PythonKinesisDynamoDBS3AthenaEventBridge
architecture — Kinesis, EventBridge, DynamoDB, S3 + Athena
Climate producers write into a Kinesis stream. EventBridge routes each record to DynamoDB for point lookups and to S3 for object storage, where Athena scans it columnar-style at query time. Ingestion, storage and analysis stay separable. climate feed producers Kinesis stream buffering EventBridge routing DynamoDB key-value lookup S3 object storage Athena scan on read hot path cold path
Kinesis absorbs the write rate so producers never wait on storage. EventBridge fans each record out twice: DynamoDB for point lookups where a single reading is wanted by key, and S3 for the analytical copy, which Athena scans columnar-style only when a query runs. Nothing is provisioned per query, and ingestion, storage and analysis can each be changed without touching the other two.
source ↗

AgriSense Agent

2025

A retrieval-augmented agricultural advisory agent that generates attributed crop recommendations grounded in retrieved evidence rather than unsourced text.

  • Architected the agent in Python to retrieve region-specific agricultural sources and attribute every recommendation to them.
  • Deployed the RAG pipeline on AWS with application and retrieval observability, enabling end-to-end diagnosis of latency across retrieval and inference stages separately.
  • Formulated a fixed evaluation set for repeatable retrieval-quality testing, making agent behaviour comparable across iterations instead of judged by inspection.
PythonRAGAWSObservability
architecture — API Gateway, Bedrock Knowledge Base, evaluation harness
A question enters through API Gateway and reaches the agent, which retrieves region-specific sources from a Bedrock Knowledge Base and passes them to a model for generation. Retrieval and inference are traced separately, and a fixed evaluation set exercises the same pipeline offline. latency traced per stage question by region API Gateway entry point agent Python · RAG Knowledge Base retrieval · Bedrock model Bedrock · OpenAI answer with sources evaluation set fixed · repeatable
Retrieval and generation are separate stages, and they are traced separately — so when an answer is slow, it is clear whether the knowledge base or the model was responsible. Every recommendation carries the sources it was built from. The fixed evaluation set runs the same pipeline offline, which is what makes a retrieval change comparable against the previous one instead of judged by reading a few answers.
source ↗

also built

AWS 3-Tier Infrastructure Platform

academic · 2026

Modular Terraform infrastructure deploying a 3-tier AWS architecture entirely as code.

  • Five modules — networking, security, compute, storage, monitoring — deploying ALB → ASG web tier → RDS, with databases isolated in private subnets behind a NAT Gateway.
  • Conditional resource counts let one shared codebase support dev, staging, and prod without duplication.
TerraformEC2ALBASGRDS

Surge

academic · 2026

A message-driven pipeline that autoscales EKS worker pods against queue depth.

  • SNS → SQS → EKS workers, with a KEDA ScaledObject scaling pods from 1 to 10 on queue depth, polling every 15 seconds.
  • EKS provisioned via eksctl, KEDA deployed through Helm, IAM inline policies scoped to least privilege; scale-out and scale-in validated under a 100-message load test.
EKSKEDASNSSQSHelm

Polyglot Healthcare System

2026

A healthcare records system using three databases, each chosen for the queries it is actually good at.

  • Python model and repository layer over PostgreSQL, isolating SQL from business logic so clinical workflows compose without touching driver details.
  • Neo4j catalog spanning diseases, medications, symptoms, and lab tests, enabling traversal-based drug-interaction checks that gate prescriptions before they reach the system of record.
PostgreSQLMongoDBNeo4jDocker

source ↗

Driver Drowsiness Detection

published · 2023

Real-time driver-fatigue detection on Raspberry Pi, without specialised in-vehicle hardware.

  • Detection and alert workflow built around real-time facial and eye-state analysis using OpenCV and Dlib.
  • Findings published and presented at Hinweis ASIT 2023.
OpenCVDlibRaspberry Pi

experience

WORK

SHRAM · backend lead
TIAA · software analyst

STUDY

B.E. Computer Science · Mumbai
M.Eng. Cloud Engineering · UMD
20202021202220232024202520262027

WORK

Jul 2023 — Nov 2025
TIAA · Software Analyst

Automated a 100+ test regression suite from 2 hours to 15 minutes, and traced participant data across MuleSoft, MDM, Snowflake and Salesforce to find where records diverged.

Nov 2021 — Jan 2023
SHRAM · Backend Team Lead

Led three engineers through a Spring Boot to Node.js migration with a ~2-hour production cutover, keeping REST API contracts intact while the legacy system stayed live. Part-time, alongside undergraduate coursework.

Jun — Jul 2022
TIAA · Student Intern

Django REST Framework APIs for an AI/NLP application. TIAA brought me back as a full-time analyst the following year.

EDUCATION

Jan 2026 — Dec 2027
University of Maryland · M.Eng. Cloud Engineeringcurrent

Advanced Networking · Databases · Cloud Computing · Linux System Administration · Virtualization and Container Technology

Aug 2019 — May 2023
University of Mumbai · B.E. Computer Science and Engineering

Operating Systems · Computer Networks · Distributed Systems · Database Systems · DSA

publication

Driver Drowsiness Detection and Alert System

Published and presented at Hinweis ASIT 2023 — Second International Conference on Advances in Software Engineering and Information Technology.

leadership

  • NSS Lead — National Service Scheme

    Led nonprofit education and outreach initiatives reaching 500+ underprivileged children.

  • Women in Tech Lead — Google Developer Student Clubs, RAIT

    Organised technical events and mentored students.

  • Intern Lead — SDG Cell, RAIT

    Mentored 27 interns and coordinated stakeholders across project delivery.

skills

Core

What I will defend in depth, unprompted.

languages

PythonJavaC++JavaScriptSQLBash

cloud and infrastructure

EC2VPCECSEKSS3RDSSQSSNSKinesisEventBridgeAthenaElastiCacheCloudWatchIAMTerraformDockerKubernetesLinux

backend and apis

Node.jsExpressSpring BootDjangoDjango REST FrameworkFlaskREST API designEvent-driven architecture

databases and data

MySQLMariaDBPostgreSQLDynamoDBSnowflakeRedisMongoDBNeo4j

software engineering

CI/CDAutomated testingSelenium WebDriverTestNGCopadoObservabilityDistributed systemsAuth & authorizationDSA

tools

GitJiraSplunkHelmeksctl

contact

Get in touch