What I Did as a Senior Engineer — Architecture, Trade-Offs & Technical Judgment
I stopped being evaluated on lines of code. I was evaluated on decisions — what architecture to use, what trade-offs to accept, and how to guide other developers. This is the real story of designing IoT telemetry for 50K events/sec, microservices for Australia's largest insurer, and the stack decision that became my most-read article.
Faisal Affan
- What I Did as a Senior Engineer
- The Senior Proposition
- Case Study 1: Petrosea Minerva — IoT Fleet Telemetry
- The Architecture Decision
- Impact
- Case Study 2: IAG Cybera360 — Insurance Platform Architecture
- The Critical Trade-Off
- Impact
- Case Study 3: Why Golang — The Stack Decision
- Architecture Diagrams I Designed
- My Senior Scorecard
- Advice for Engineers Transitioning to Senior
- Document Every Architecture Decision — Even the Wrong Ones
- Mentoring Is Not Optional
- Write Publicly — Your Engineering Portfolio Compounds
- Measure Everything, Optimize What Matters
- What I'd Do Differently
What I Did as a Senior Engineer
"You don't become a senior engineer by writing more code. You become one by making decisions that outlive you." — Me, after breaking production for the 47th time
The jump from mid-level to senior is the most disorienting transition in engineering. Your mid-level years taught you to ship features. Now, nobody cares how fast you personally ship. They care whether the architecture you chose survives three years of growth, whether the trade-offs you documented save the next team six months of rediscovery, and whether the junior engineers you mentored can ship without you.
The Senior Proposition
What Changed
Before (Mid-Level): "Can you own a feature end-to-end and ship it reliably?" Now (Senior): "Can you make architectural decisions that multiple teams will follow — and be right about the trade-offs 80% of the time?"
I stopped being evaluated on lines of code. I was evaluated on decisions — what architecture to use, what trade-offs to accept, and how to guide other developers without writing their code for them.
Here is what that actually looked like in practice.
Case Study 1: Petrosea Minerva — IoT Fleet Telemetry
Role: Backend Engineer & System Architect Stack: Go, MQTT, Kafka, TimescaleDB, React Scale: 50K telemetry events/second, 100+ heavy equipment units across 3 remote mining sites
Petrosea's mining operations had a problem: 100+ dump trucks, excavators, and support vehicles operating across remote sites in Kalimantan generated continuous telemetry — GPS position, engine temperature, fuel consumption, payload weight — every 2 seconds. The data was critical for real-time dispatch decisions, geofence alerts, and predictive maintenance. But the sites had intermittent satellite connectivity that made HTTP-based architectures unreliable.
The Architecture Decision
I designed a real-time geofencing engine capable of processing 50K events per second with sub-2-second alert latency. The core architectural choice was the data pipeline:
Impact
| Metric | Before | After |
|---|---|---|
| Telemetry processing | Manual/log-based | Real-time, 50K events/sec |
| Geofence alert latency | 5-10 minutes | < 2 seconds |
| Fuel theft detection | Unknown (undetected) | Caught in month one |
| Annual savings | — | Rp 3.2B ($200K) |
| Fleet utilization visibility | Paper-based shift reports | Live dashboard, 65% → 79% |
Case Study 2: IAG Cybera360 — Insurance Platform Architecture
Role: Frontend & Backend Engineer Stack: Nuxt.js (SSR), Go microservices, PostgreSQL, D3.js Scale: 5+ partner integrations, digitized entire insurance lifecycle for Australia's largest insurer
IAG (Insurance Australia Group) — Australia's largest general insurer, ~AU$12B market cap — needed a platform to serve the underserved SME cyber insurance market. The existing process took 3-4 days for a quote, involved 100+ manual questions, and required underwriter back-and-forth via email. We had to digitize the entire lifecycle: risk assessment → quoting → binding → monitoring → claims.
The Critical Trade-Off
Impact
| Metric | Before | After |
|---|---|---|
| Quote turnaround | 3-4 days | < 15 minutes |
| Insurance lifecycle | Manual/paper | Fully digitized |
| Partner integrations | None | 5+ (UpGuard, Acronis, RHCS, etc.) |
| Platform reach | Australia only | Asia Pacific (Singapore, Malaysia, Hong Kong) |
Case Study 3: Why Golang — The Stack Decision
Role: Technology Decision-Maker Stack: Go (chosen), evaluated against Node.js, Python, Rust
Every senior engineer eventually faces the question: "What's your primary stack and why?" This isn't a trivia question — it's a test of your ability to evaluate trade-offs across multiple dimensions: performance, developer productivity, ecosystem maturity, hiring market, and long-term maintenance cost.
I evaluated four options against five criteria:
| Criterion | Go | Node.js | Python | Rust |
|---|---|---|---|---|
| Concurrency model | Goroutines (built-in) | Event loop (single-threaded) | GIL-limited | Async/await (complex) |
| Compilation speed | < 2 seconds | N/A (interpreted) | N/A (interpreted) | 30-120 seconds |
| Deployment | Single binary | Node + node_modules | Python runtime + pip | Single binary |
| Learning curve | Low (25 keywords) | Low | Low | Steep (ownership, lifetimes) |
| Hiring in Indonesia | Growing rapidly | Mature | Mature | Niche |
The Decision: Go won on simplicity, compilation speed, and deployment ergonomics — not raw performance. A Rust advocate could correctly point out that Rust outperforms Go in CPU-bound workloads by 2-5x. But raw CPU throughput was rarely my bottleneck. Network I/O, database queries, and message queue throughput were. Go's goroutine-based concurrency model handles those perfectly.
The Recurring Pattern
Every senior-level decision in my career followed the same pattern: identify the real constraint (not the hypothetical one), evaluate trade-offs explicitly, and choose the option that optimizes for the bottleneck — whether that's developer productivity, deployment simplicity, or SEO requirements.
Architecture Diagrams I Designed
Beyond individual projects, the senior role demanded that I document architecture decisions so they could be understood, challenged, and extended by other engineers. Here are two key diagrams that represent the most complex architectural problems I solved.
My Senior Scorecard
| Portfolio Item | Did I Do It? | Evidence |
|---|---|---|
| System architecture diagrams | ✅ Documented across multiple case studies with trade-off analysis | |
| Trade-off decisions with rationale | ✅ Go vs Rust, MQTT vs HTTP, SSR vs SPA — each with explicit evaluation matrix | |
| Mentorship impact | ⚠️ Informal mentoring only — never created a structured program | |
| Speaking/writing | ✅ 20+ published technical articles including most-read Go stack analysis | |
| Cross-team architecture influence | ✅ Designed patterns adopted by 3+ product teams (form engine, telemetry pipeline) | |
| Production incident leadership | ✅ Led RCA for critical IoT incidents, documented runbooks for ops handover | |
| ADR / technical documentation | ⚠️ Inconsistent — decisions documented in case studies but not formal ADRs in every case |
The informal mentorship column is my biggest gap. I guided juniors and mid-level engineers on their code reviews and architecture decisions, but I never created a structured mentorship framework. Looking back, that was a missed opportunity — the engineers I informally mentored grew faster, but the organization couldn't replicate the pattern because it wasn't documented.
Advice for Engineers Transitioning to Senior
Document Every Architecture Decision — Even the Wrong Ones
The difference between a senior and a mid-level isn't making perfect decisions — it's being able to articulate why you made a decision, what alternatives you considered, and when you'd revisit it. Start writing ADRs (Architecture Decision Records) for every non-trivial technical choice. The Go-stack analysis I published became my most-read article not because it was technically impressive, but because it showed the evaluation matrix — the exact same format you need for your senior portfolio.
Mentoring Is Not Optional
You don't become a senior by knowing more. You become one by making others more effective. Start with one junior engineer. Code review with explanation ("I'd do X because Y, but your approach works if Z"). Pair program on a complex feature. Write internal documentation that unblocks the team. The compound interest of mentoring pays off faster than any individual feature you could build.
Write Publicly — Your Engineering Portfolio Compounds
Every architecture decision, trade-off analysis, or production postmortem you write is an asset. It validates your thinking for future employers, helps other engineers facing the same problems, and builds recognition that makes senior roles easier to secure. I wrote 20+ technical articles during my senior years — and every single one of them contributed more to my career trajectory than any single feature I shipped.
Measure Everything, Optimize What Matters
Mid-level engineers optimize for "does it work." Senior engineers optimize for "does it survive." Latency, throughput, error budgets, MTTR, deployment frequency — these aren't DevOps metrics. They're senior engineering metrics. Start measuring before you optimize. The "$200K annual savings" from Petrosea exists because I instrumented the system from day one and could point to specific improvements with specific dollar values.
What I'd Do Differently
- Formalize mentorship earlier. The junior and mid-level engineers I guided informally are the ones I'm most proud of. But I should have created a repeatable pattern — tech talks, pair programming schedules, growth checklists — that outlived my presence.
- Write formal ADRs for every major decision. I documented trade-offs in case studies but not in the machine-readable ADR format that organizations need for institutional memory.
- Say "no" more clearly to non-senior work. The hardest transition was learning that my job wasn't to write more code. Every hour I spent building a feature was an hour I didn't spend reviewing architecture, unblocking a teammate, or documenting a decision. The seniors who excel are ruthlessly strategic about where they invest their time.
Senior engineering is not the ceiling. It's the launching pad. The architecture decisions you make at this level outlive your tenure. The engineers you mentor outgrow your influence. The trade-offs you document save future teams years of rediscovery. Your code compiles and deploys. But your decisions compound — and that's what makes a senior engineer.