Engineering Leadership & Cross-team Influence

# RFC: Migrate Internal Services sang gRPC

**Author**: @khoa
**Status**: Draft | In Review | Accepted | Rejected | Superseded
**Reviewers**: @backend-team, @devops, @mobile-team
**Created**: 2024-03-15
**Decision Deadline**: 2024-03-29

## Problem Statement (Vấn đề)
Hiện tại các internal services giao tiếp qua REST JSON.
Benchmarks cho thấy serialization overhead ~30% request latency
cho high-frequency calls giữa order-service và inventory-service
(~10K calls/second at peak).

## Proposed Solution
Migrate internal service-to-service communication sang gRPC/Protobuf.
REST endpoints giữ nguyên cho external API.

## Why gRPC?
- Binary serialization (Protobuf): ~5-8x faster than JSON serialize/deserialize
- HTTP/2 multiplex giảm connection overhead
- Strongly typed contracts → catch breaking changes at compile time
- Bidirectional streaming cho real-time use cases

## Impact Analysis (Ai bị ảnh hưởng?)
- Backend team: Phải học Protobuf, update service clients
- DevOps team: Cần update load balancer config, health check (gRPC != HTTP)
- Mobile team: Không ảnh hưởng (external API vẫn REST)

## Migration Plan
Phase 1 (2 weeks): Setup gRPC framework, migrate 1 low-risk service pair
Phase 2 (4 weeks): Migrate high-traffic services (order ↔ inventory)
Phase 3 (ongoing): Migrate remaining services

## Alternatives Considered
1. **Optimize JSON**: Giảm payload size, thêm compression.
   Rejected: Ước tính chỉ giảm 10-15% latency, không đủ.
2. **MessagePack**: Compact binary JSON alternative.
   Rejected: Ít tooling support, không có schema enforcement.
3. **Keep REST**: No migration cost.
   Rejected: Performance không đạt target SLO.

## Open Questions
- [ ] gRPC load balancing strategy với K8s? (L7 vs L4)
- [ ] Backward compatibility khi có mixed gRPC/REST services trong transition?

## Success Metrics
- p99 latency giảm ≥ 25% cho order-inventory calls
- Zero downtime migration
- No increase in error rate during migration

Week 0: Viết draft, share với 2-3 stake holders thân cận lấy early feedback
        (Đừng public khi draft còn lộn xộn)

Week 1: Share lên tech channel / mailing list
        Đặt deadline review rõ ràng (không phải "khi nào có giờ")
        Tag people cụ thể nếu cần input từ họ

Week 1-2: Respond to comments trong vòng 24h
          Update RFC dựa trên feedback đáng giá
          Resolve disagreements async, nếu deadlock thì schedule sync

Week 2+: Decision meeting (nếu cần) với key stakeholders
         Document final decision và rationale
         Update status → Accepted hoặc Rejected

Post-decision:
  Nếu Accepted: Create tickets, assign owners, set milestones
  Nếu Rejected: Document tại sao để tránh re-litigating

Cần có Standards:
  - API design guidelines (REST/gRPC conventions, versioning, error codes)
  - Error handling patterns
  - Logging format và log levels
  - Security baseline (auth, input validation, secrets management)
  - Testing expectations (unit vs integration, coverage targets)
  - Code review process (SLA, blocking criteria)

Không cần Standards (hoặc Light guidelines):
  - Code style (delegate cho formatter: gofmt, prettier, black)
  - Library choices cho non-critical features
  - Internal variable naming trong module scope

1. Involve people trong quá trình tạo standard
   → Workshop với engineers từ nhiều team
   → Gather pain points, collect existing practices
   → Draft standard dựa trên thực tế, không phải ideal

2. Start with exemplar
   → Implement standard trong 1 service trước
   → Document "Đây là cách chúng ta muốn làm"
   → Người khác có thể copy, không phải đọc abstract doc

3. Automate enforcement
   → Linter rule > guideline doc
   → CI check > verbal reminder
   → PR template > hoping people remember

4. Create positive feedback loop
   → Recognize khi team follows standard well
   → Make deviation visible (không phải để blame, để fix)

5. Revisit và update
   → Standard phải evolve với technology và team knowledge
   → Quarterly review: vẫn còn relevant? Có pain points?

Ví dụ Golden Path cho New Service:
  → Repository template với CI/CD, logging, tracing đã setup sẵn
  → Service template với proper error handling, health check endpoint
  → Deployment template với resource limits, pod disruption budget
  → Monitoring dashboard template với standard metrics

Kết quả:
  - Engineer mới tạo service: Copy template → Customize → Done
  - Không cần đọc 10 docs về "best practices"
  - Standard được enforce tự nhiên vì infrastructure supports it

Với Engineers:
  Technical precision là tôn trọng
  "P99 latency tăng 3x, từ 270ms → 800ms sau commit abc123
   Root cause: eager load N+1 trong UserRoleResolver, fixed với DataLoader
   Impact: 0.3% requests timeout, ~150 users affected in 20-min window"

Với Product/Business:
  Impact + action là tôn trọng
  "Login chậm trong khoảng 20 phút tối qua, ảnh hưởng đến khoảng 150 user.
   Đã fix xong và deploy lúc 23:15. Đang add monitoring để phát hiện sớm hơn
   trong tương lai. Cần bạn confirm có muốn thông báo cho users affected không?"

Situation: "Chúng ta đang scale service X để support growth kế hoạch."
Complication: "Tuy nhiên, architecture hiện tại có bottleneck ở database layer,
               sẽ bắt đầu có issue khi đạt ~50K concurrent users — ước tính Q3."
Question: "Chúng ta nên làm gì để chuẩn bị?"
Answer: "Đề xuất của mình là đầu tư 3 sprint trong Q2 để implement read replicas
         và connection pooling — cost khoảng $X/month infra + Y engineer weeks.
         Điều này sẽ extend capacity đến ~200K concurrent users, đủ cho đến Q1 năm sau."

1. Tham gia vào planning, không chỉ execution
   → Sprint planning, quarterly planning, OKR setting
   → Raise engineering concerns sớm, không phải khi đã commit

2. Sử dụng ngôn ngữ tradeoff, không phải "không được"
   → ❌ "Tính năng đó không làm được."
   → ✅ "Tính năng đó trong 2 tuần là risky vì thiếu test coverage.
         Nếu cần 2 tuần thì đây là phần của scope bị cut.
         Hoặc 4 tuần để làm đúng. Bạn muốn tradeoff nào?"

3. Hiểu business priority thực sự
   → Đôi khi "nhanh và đúng" là quan trọng hơn "chậm và perfect"
   → Đôi khi ngược lại (payment system, healthcare)
   → Context là tất cả

4. Celebrate shipping cùng nhau
   → Engineering và Product thành công hay fail cùng nhau
   → Avoid "us vs them" mentality

Challenges của Cross-team Work:
  - Không có shared context (mỗi team biết system của mình, không biết của team kia)
  - Không có shared priority (Team A cần feature X, Team B cần Y, cả hai cần Team C)
  - Không có clear ownership (ai own cross-cutting concern?)
  - Coordination overhead tăng theo n² với số teams

## Working Agreement — Project: Unified Auth System

**Teams involved**: Platform, Backend, Frontend, Mobile

**Decision making**: RFC process cho architecture decisions
  → Author: Platform team
  → Reviewers: All team leads
  → Deadline: 5 business days per RFC

**Communication channel**: #auth-v2 Slack channel
  → Async by default
  → Sync meeting: Bi-weekly 30 min status call

**API Contract changes**: Require 2-week notice + migration guide
  → No breaking changes without deprecation period

**Escalation path**: 
  → Team lead → VP Engineering (if blocked > 3 biz days)

**Success metrics**:
  → Auth latency p99 < 100ms
  → Zero breaking changes for mobile clients
  → Go-live: 2024-06-01

Giảm risk dependency:
  1. Early alignment: Làm rõ requirements với team kia sớm
     → Đừng để "mình cần feature X" → 2 tuần sau → "ôi tưởng X nghĩa là..."
  
  2. Interface-first: Define API/contract trước, implement sau
     → Mock interface để cả 2 teams build parallel
     → Contract test để catch divergence sớm
  
  3. Regular check-ins: Weekly sync không phải để update status
     → Để unblock blockers sớm, không phải để biết "đang làm"
  
  4. Fallback plan: Nếu team kia deliver muộn, plan B là gì?
     → Build stub? Reduce scope? Extend timeline?
     → Biết plan B trước thì khi xảy ra bạn không panic