← Back

AT&T · 2021 – Present

Real Estate Rights Calculator

70K+ cell sites$5M in prevented penalties$150K operational savings
JavaSpring BootKafkaOracle

Overview

The Real Estate Rights Calculator (RERC) is a tool used by RF design engineers to verify that a cell tower design stays within the square inch allotment in AT&T's lease agreements. On a shared tower, multiple carriers each have a designated RAD Center where their antennas are installed, and each carrier has a contractually defined amount of space they can use. A design that goes over that limit risks interference with neighboring carriers and triggers fees or forces renegotiation.

RERC takes an engineer's RFDS (Radio Frequency Data Sheet) as input, calculates the total square inch usage of the design, and tells the connected design tool whether the design is compliant. Catching an overage early is critical. If it surfaces further down the line, fixing it means redesigning the site, paying fees, or renegotiating lease agreements.

The Challenge

Why the Rebuild Was Worth It

Legacyhard to test
  1. 1MuleSoft API
  2. 21,500-line stored procedure
  3. 3Fragile catalog lookup
Rebuilt3-month launch
  1. 1Spring Boot service
  2. 2Testable Java logic
  3. 3Kafka-backed equipment data

The RERC had been owned by another team and built as a MuleSoft API backed by a 1,500-line Oracle stored procedure that calculated equipment square inches one piece at a time. It had known miscalculation issues and was slow to support new features. The owning team had too many applications to give RERC real attention, so our team took ownership.

That meant making an architectural call: lift-and-shift, or rebuild. My principal architect favored a lift-and-shift for speed to market. I pushed for a rebuild. Our existing CI/CD pipelines and Kubernetes infrastructure were built for Java Spring Boot, so spinning up a new service would be simple. Moving the business logic out of a 1,500-line stored procedure into Java would make it testable, debuggable, and maintainable in a way that stored procedures fundamentally are not. MuleSoft also carried licensing costs we could eliminate, and keeping it would have created a separate infrastructure path to maintain indefinitely.

We worked through it and landed on a middle ground: migrate to Spring Boot, refactor the critical calculation logic, and keep the Oracle database to hit the 3-month timeline. I built it solo.

What I Built

Compliance Check Flow

Input

RFDS design

equipment list + site constraints

Data

Equipment cache

local dimensions for common components

Service

RERC API

validates request, coordinates calculations, returns compliance status

Compute

Antenna
Mount
Cable

Parallel equipment calculations aggregate into total square-inch usage.

Output

Compliance result

within lease allotment or overage risk

Events

Kafka updates

catalog changes refresh local equipment data

I built the new RERC service using a test-driven approach. The main architectural change was parallelizing the equipment calculations. The original stored procedure calculated each equipment piece sequentially. I refactored this so all calculations run concurrently and aggregate once they are complete, cutting the API response time from 1 minute to 20 seconds.

While rebuilding the logic I found several underestimation bugs in the original calculations. Designs that appeared compliant were actually over their square inch allotment. These fixes were a key part of the accuracy improvements that drove the post-launch outcome.

I also replaced a fragile database link to the Equipment Catalog with a Kafka-based integration. The old DB link was unreliable and often returned stale equipment dimensions. Now when the catalog team updates a dimension, an event is published and RERC updates its local copy in real time, with a local cache of the most commonly used equipment for faster lookups.

Outcome

Launch Impact

1 minute20 seconds

API response time

MuleSoft cost$150K/year

operational savings

missed overages$5M

potential costs surfaced

The service launched defect-free with 90% code coverage on a 3-month timeline. Cutting the MuleSoft license and improving calculation efficiency reduced annual operational costs by $150K. After launch, all in-progress RFDS across AT&T were re-run through the new tool as part of a maintenance audit. The more accurate calculations surfaced $5 million in potential overage fees, rework costs, and re-engineering labor that the old tool would have missed.