Case study · production systems

Faster from database to deployment.

A sanitized case study from my Boston University software engineering role, covering query optimization, caching, frontend simplification, and CI/CD.

RoleSoftware Engineer
DatesAug. 2025 - May 2026
Query improvement80%
Deployment improvement70%
01

Context

A production automation platform had accumulated friction across layers.

The work involved a live system used by internal stakeholders. The public explanation stays at the architectural level and excludes proprietary data, service names, operational details, and confidential workflows.

02

Architecture

The bottleneck was not in just one place.

01 React + Redux UI Operator workflow
02 FastAPI services Application boundary
03 Cache layer 6–7 ms responses
04 TimescaleDB Time-series queries
05 Docker + Actions Build and release
06 AWS EC2 Production runtime
Sanitized production architecture.
03

My ownership

Independent development with close stakeholder feedback.

I architected Python/FastAPI microservices and React/TypeScript interfaces with Redux, working with IT leadership, specialists, and project managers to define requirements, iterate on features, and release production-ready tools.

04

Bottleneck discovery

Measure boundaries, then change the right layer.

  • Profiled a critical database path rather than treating total page time as a single number.
  • Separated uncached query work from the cached response path.
  • Inspected rendered UI structure and identified more than 1,000 redundant DOM elements.
  • Measured the build-and-release workflow to find deployment delay.
05

Changes

Database, cache, interface, and delivery.

  • TimescaleDB: optimized the critical query path.
  • Server-side cache: served repeat work without re-running the expensive path.
  • React: simplified the rendered structure to improve responsiveness and maintainability.
  • GitHub Actions + Docker: automated build, test, and release steps for AWS EC2 services.
06

Results

Improvements at four distinct boundaries.

80%Reduction in critical query time
6–7 msCached response time
70%Reduction in deployment time
1,000+Redundant DOM elements removed
07

Verification

Compare the same operation before and after.

Each percentage refers to its own measurement boundary: query execution, cached service response, or deployment workflow. The numbers should not be combined into a single “system speed” claim.

08

Limitations

Sanitized means reproducibility is necessarily partial.

Because this was production work, the public case study cannot disclose the dataset, exact query, internal service topology, or workload. The useful evidence is the measurement discipline, architectural reasoning, and clearly bounded results.

09

Lesson

Performance is a systems property.

A faster query does not fix an overbuilt interface, and a cleaner interface does not fix a manual release process. Meaningful improvement came from treating the path as a connected system.