Professional Engineering

Telecommunications.

Distributed services, event-driven integrations, cloud delivery, and customer-facing systems built with production operations in mind.

Organization
T-Mobile
Role
Full Stack Engineer
Period
Feb 2025 – Present
Platform
Telecom Customer Experience Platform
Network racks and fiber connections representing telecommunications systems

Context

My telecommunications experience centers on a customer-experience platform where backend services, frontend applications, data stores, cloud infrastructure, security, and production visibility operate as one connected system.

My contribution spans Java and Spring Boot services, event-driven integrations, modern web interfaces, cloud delivery, and the operational concerns required to support distributed software in production.

Engineering Scope

  • Backend services
  • Event-driven systems
  • Cloud delivery
  • Data and caching
  • Security
  • Observability

Selected Outcomes

  • Contributed backend and frontend functionality within the same customer-experience platform
  • Supported event-driven and request-driven service integration
  • Contributed to cloud delivery, automated deployment, and production troubleshooting
Systems & Responsibilities

Service and API development

Contributed to Java and Spring Boot services and REST interfaces used within a distributed customer-experience platform.

Stable service behavior and clear interfaces support dependable integration across backend and frontend consumers.

Distributed integration

Worked with Kafka workflows and service-to-service communication alongside synchronous APIs.

Distributed communication must make delivery behavior, failure handling, and operational diagnosis explicit.

Production delivery

Contributed across containerized delivery, CI/CD, cloud services, security, and production monitoring.

Software becomes useful only when teams can deploy, observe, troubleshoot, and improve it safely.
Engineering Challenges

Mixed service communication

Challenge: A distributed platform uses both request-driven APIs and asynchronous workflows, each with different coupling and failure characteristics.

Approach: Worked across REST services and Kafka producer/consumer workflows while keeping integration behavior visible through application and platform monitoring.

Consideration: Asynchronous communication reduces temporal coupling but adds delivery, retry, ordering, duplicate-processing, and observability concerns.

Data access across stores

Challenge: Application workflows span relational data, key-value access, and caching rather than one universal persistence model.

Approach: Worked with PostgreSQL, DynamoDB, and Redis in support of workload-specific persistence and access patterns.

Consideration: Additional data technologies can improve fit and responsiveness, but increase consistency, operational, and debugging complexity.

Secure distributed access

Challenge: Customer-facing and service-level interactions require consistent authentication and authorization across boundaries.

Approach: Contributed within security flows using OAuth 2.0, JWT, Okta, mTLS, and cloud access controls.

Consideration: Stronger identity boundaries improve protection but require careful token handling, service identity, certificate management, and least-privilege configuration.
Technology by Responsibility

Backend

Java 17 · Spring Boot · Spring Cloud · Hibernate · REST APIs

Messaging

Kafka · Asynchronous workflows

Data

PostgreSQL · DynamoDB · Redis

Frontend

React · Angular · TypeScript

Cloud and delivery

AWS · Docker · Kubernetes · CI/CD

Security

OAuth 2.0 · JWT · Okta · mTLS

Observability

Datadog · Grafana · CloudWatch · ELK

Improvements, Decisions & Outcomes

Improvements

  • More maintainable service and API integration
  • Responsive data access supported by workload-appropriate persistence and caching
  • Repeatable container and CI/CD delivery
  • Stronger production visibility across application and cloud behavior
  • Consistent authentication and authorization across system boundaries

Decisions & trade-offs

Work within event-driven communication

Supports asynchronous processing and reduces direct request-lifecycle coupling between participating services.

Requires explicit handling for delivery behavior, retries, ordering, duplicate processing, and consumer observability.
Use multiple data technologies by workload

Relational storage, key-value access, and caching serve different application access patterns.

Multiple stores increase consistency decisions, operational overhead, and the number of failure modes engineers must understand.
Treat observability as production functionality

Distributed failures are difficult to diagnose from any single service or log stream.

Useful telemetry requires consistent instrumentation, meaningful signals, and ongoing attention to noise and cost.

What I learned

  • Distributed communication needs explicit failure and delivery semantics.
  • Caching and persistence choices should follow access patterns rather than convention.
  • Security must remain consistent across user, service, and cloud boundaries.
  • Observability must exist before production behavior needs to be diagnosed.
  • Delivery automation and application design are parts of the same production system.