EVErica Vaughn

Case study 09 · Reliability · Production engineering

Planning Platform Reliability & Performance

A collaborative demand-planning app managing events, demand, and inventory views slowed down and went intermittently unavailable as usage grew. I traced the problem across the app, the database, and the jobs that feed it.

01 · The challenge

The symptom showed up in the app. The cause didn’t live there.

Users were hitting slow pages and intermittent outages. Meanwhile, table growth and lagging database maintenance made it hard to tell application symptoms apart from root causes.

The causes ran across Databricks processing, PostgreSQL serving tables, scheduled jobs, migrations, and deployment.

02 · What I did

What I owned and built.

  • Investigated production latency and service errors across the web application and the PostgreSQL database.
  • Analyzed dead tuples, delayed autovacuum, and index bloat, and isolated the most affected demand and history tables.
  • Traced the read paths for event editing, the timeline, and demand history to show where query and materialization changes would help.
  • Identified lock contention and expensive rebuild patterns in the processing that feeds the serving tables, and shaped a more resilient design.
  • Separated short-term incident recovery from longer-term monitoring, query optimization, and data-model changes.

03 · Architecture

How it fits together.

Databricks processing
Scheduled jobs
Serving tables
PostgreSQL: dead tuples · autovacuum lag · index bloat
Read paths
Event editing · timeline · demand history
Application
Vercel
Observability
Sentry

04 · Key decisions

The judgment behind the build.

Why investigate across layers?

Fixing the layer where a symptom appears often just moves the problem. Following the request path end to end is how you find what actually changed.

Why treat bloat as a design problem?

Dead rows and index bloat are usually a byproduct of how data gets written. Changing the write pattern prevents them from coming back.

Why lead with observability?

You can’t prioritize what you can’t see. Error and timing signals turned anecdotes into evidence.

05 · Impact

What changed because of the work.

3root-cause areas isolated
6+layers traced end to end
2-trackrecovery vs. long-term plan
  • Turned a vague performance incident into specific, testable hypotheses about database maintenance and application reads.
  • Set clear technical priorities for a more reliable planning workflow.
  • Built shared understanding across application, data, and business teams.

06 · What’s next

Where it goes from here.

Implement and validate the agreed remediation, track table health, and measure user-facing latency after the changes.

This case study is a sanitized reconstruction. Organization names, proprietary code, data, and internal schemas are intentionally left out.