Forem: PETER ABAH

⏱️ When “One Month” Means One Month: Lessons I Learned About Engineering Timelines, Pressure, and Professional Growth

PETER ABAH — Thu, 26 Feb 2026 19:18:36 +0000

Recently, I had an experience that fundamentally changed how I think about engineering timelines, communication, and professional responsibility.

I was tasked with building a web application using Angular and .NET to mimic the process flow of an existing payment collection system.

The expectations were clear:

🧩 Develop the application
🚀 Deploy to UAT
🎤 Conduct stakeholder demo
🌍 Go live

All within one month.

As an engineer with experience in Angular, .NET, IIS deployments, authentication flows, and CI/CD pipelines, I was confident. Challenged—but confident.

But software engineering always has a way of teaching deeper lessons.

🔐 The Unexpected Blocker

After shipping the initial build to the staging environment, I began integrating authentication using MSAL.

That’s when I encountered a blocker:

⚠️ MSAL requires HTTPS in staging environments for security compliance.

The staging environment was not properly configured for HTTPS. This wasn’t a code issue—it was an infrastructure dependency affecting multiple applications.

During stand-up, I communicated the blocker and explained the dependency.

The response I received was simple and direct:

“We shouldn’t be making excuses. This should be done within a month.”

That moment became a turning point for me—not emotionally, but professionally.

It forced me to reflect deeply on what it means to be an effective engineer beyond just writing code.

🧠 Reality Check: Software Development Is More Than Coding

Building production-ready software involves far more than implementing features.

It includes:

📋 Understanding and validating requirements
🏗️ Designing reliable architecture
🔐 Implementing secure authentication
🔄 Integrating frontend and backend systems
🧪 Testing, debugging, and validation
🚀 Deploying across environments
👥 Supporting UAT and production readiness

Each layer introduces dependencies.

Some are code-related. Others are environmental, infrastructural, or organizational.

Experience helps you navigate complexity—but it doesn’t eliminate complexity.

🗣️ The Most Valuable Skill I Strengthened: Communication

This experience taught me that communication is not a soft skill in engineering—it’s a technical survival skill.

I learned to frame updates differently.

Instead of saying:

“I’m blocked by MSAL requiring HTTPS.”

I learned to say:

“Core functionality is complete. Remaining work depends on staging environment HTTPS configuration required for secure authentication. Once resolved, integration can be completed within 2–3 days.”

Same reality. Different framing.

One sounds like a delay.

The other communicates progress, ownership, and clarity.

This small shift makes a massive difference in how engineering work is perceived.

⚖️ The Engineering Triangle: Scope, Timeline, Quality

This experience reinforced a principle every engineer should understand:

You can optimize for:

📦 Scope
⏱️ Timeline
✅ Quality

But not all three at the same time.

If timeline is fixed → scope must be reduced
If scope is fixed → timeline must increase
If both are fixed → quality suffers

This isn’t opinion. It’s physics.

Professional engineers don’t just build systems—they protect system reliability.

🧩 What Separates Mid-Level Engineers from Senior Engineers

I realized that engineering growth isn’t just about writing better code.

It’s about learning to:

🎯 Communicate progress in business terms
⚠️ Identify and communicate risks early
🧠 Think in systems, not just tasks
🤝 Align technical reality with business expectations
🧘 Remain calm and professional under pressure

Senior engineers don’t just solve technical problems.

They reduce uncertainty.

🚀 The Shift in My Mindset

This experience didn’t make me defensive.

It made me more intentional.

I now focus on:

Communicating dependencies clearly
Framing blockers as risks with timelines
Structuring updates around progress and next steps
Thinking beyond implementation to delivery and stability

Engineering is not just about getting software to work.

It’s about getting software to work reliably, securely, and sustainably.

💡 Final Thoughts

Every engineer will eventually face:

Aggressive timelines ⏱️
Infrastructure blockers 🔧
High stakeholder expectations 📈

These moments test more than your coding ability.

They test your professionalism, communication, and leadership.

The biggest lesson I learned is this:

👉 Great engineers don’t just write code.

They create clarity.

And clarity is what allows great software—and great teams—to succeed.

If you’ve had similar experiences, I’d love to hear what lessons they taught you.

🚨 When “It Works” Isn’t Good Enough: Diagnosing Token Bottlenecks in Distributed Systems

PETER ABAH — Sat, 14 Feb 2026 15:23:04 +0000

One of the most interesting engineering challenges I’ve worked through recently had nothing to do with syntax, frameworks, or libraries.
It was about asking the right questions.
The situation
We had multiple internal services calling a third-party API secured by OAuth access tokens.
The access token was stored in a database and shared across services.
The flow looked reasonable at first glance:
Services read the token from the DB

Call the third-party resource

If a 401 Unauthorized occurs → refresh token → update DB

But something didn’t feel right.

The red flags 🚩
When you zoom out and think systemically, a few problems jump out:
Hot-spot database access
Every outbound request depended on a DB read.

Race conditions under load
Multiple services could refresh the token at the same time.

Thundering herd problem
One expired token → many simultaneous refresh calls.

Tight coupling
Business services were now coupled to auth lifecycle concerns.

Hidden latency amplification
DB → auth endpoint → DB, multiplied across services.

This kind of design often survives early testing… and fails spectacularly at scale.

The proposed fix (and why it still wasn’t enough)
An idea came up to:
Run a database job that checks token expiry

Maintain an IsExpired flag

Let a dedicated service refresh the token

Ask other services to “wait and retry” when a 401 occurs

This was a good instinct — it tried to centralize responsibility.
But it still had issues:
Token expiry ≠ token invalidation

Polling introduces lag and inconsistency

Artificial delays degrade user experience

The database was still being used as a coordination mechanism

Better… but not robust.

The mental model shift 🧠
Here’s the key realization:
Access tokens are not business data.
They’re volatile secrets — like TLS certificates or signing keys.
Once you adopt that mindset, the architecture becomes clearer.

The industry-proven pattern
Instead of every service “knowing” about tokens:
👉 Introduce a Token Broker / Auth Gateway
One service owns the token lifecycle

Other services simply ask for a valid token

Refresh is protected by in-memory locking

The database becomes a fallback, not a hot path

No Redis required (important in locked-down corporate Windows environments)

This eliminates:
Refresh stampedes

DB contention

Race conditions

Authentication logic leakage into business services

And it dramatically improves reliability, performance, and clarity of ownership.

Why this matters (especially for senior roles)
This wasn’t about writing clever code.
It was about:
Identifying hidden bottlenecks

Challenging designs that “work” but don’t scale

Applying battle-tested system patterns

Understanding how distributed systems fail in real life

Designing within real-world constraints (security policies, OS limitations, infra restrictions)

That’s the difference between:
“I can implement features”
and
“I can design systems organizations can trust under load.”

Final thought
Great systems aren’t built by adding more logic.
They’re built by removing unnecessary responsibility from the wrong places.
If you’re designing mission-critical systems:
Always ask who truly owns this concern?

Watch for shared mutable state

Be suspicious of “just add a DB flag” solutions

Optimize for clarity, ownership, and failure modes

That’s where real engineering impact lives.

💬 I’d love to connect with engineers, architects, and leaders who enjoy deep system design conversations.

SystemDesign #SoftwareArchitecture #DistributedSystems

#BackendEngineering #Scalability #PerformanceEngineering
#SeniorDeveloper #TechLeadership #EngineeringMindset