AT&T · 2021 – Present
Real Estate Rights Calculator
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
- 1MuleSoft API
- 21,500-line stored procedure
- 3Fragile catalog lookup
- 1Spring Boot service
- 2Testable Java logic
- 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
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
API response time
operational savings
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.