Skip to content

Day 140 — Month 5 Review + Tag v0.5.0

Month 5 · Week 4 · ⬅ Day 139 · Day 141 ➡ · Journal index

🎯 Learning Objective

Consolidate Month 5 — gRPC, architecture, and a resilient queue microservice — through active recall, ship the capstone, and tag the v0.5.0 release.

📚 Topics

  • Week 4 capstone: gRPC skeleton → hexagonal layers → Redis queue → retries/DLQ → tests/metrics → docs/ADRs
  • Month 5 throughline: protobuf/gRPC wire & error model → interceptors/TLS/transcoding → architecture → microservice
  • Release engineering: tagging v0.5.0, release notes

📖 Reading / Sources

📝 Notes

  • This is a lighter review day — the full Week 4 retrospective, re-quiz, and metrics live in week-4-review.md; the month-level summary, interview readiness, and portfolio updates live in month-05-review.md.
  • One-line throughline for the month: a service is a core wrapped in adapters wrapped in middleware — the domain owns its ports, adapters (gRPC, Redis, metrics) plug into them, and interceptors add cross-cutting behavior. Resilience (retries, backoff, jitter, DLQ, idempotency) is what makes it survive the real world → [[hexagonal]] [[job-queue]] [[idempotency]].
  • The capstone ties Months 1–5 together: types/errors (M1), stdlib/testing (M2), concurrency (M3 — the worker pool), web/DB (M4), and gRPC/architecture (M5).
  • Ship it: commit the docs, then git tag -a v0.5.0 and write release notes.

💻 Code Examples

# Tag the Month 5 release.
git tag -a v0.5.0 -m "Month 5: gRPC, architecture & a resilient queue microservice"
git push origin v0.5.0

Re-run this week's stdlib rebuilds: go run ./examples/month-05/jobqueue · .../workerpool · .../retry · .../metrics · Tests: go test ./exercises/month-05/week-4/...

🏋️ Exercises / Practice

Exercise Status Link
All Week 4 exercises pass go test (incl. -race) ✅ exercises/month-05/week-4

🐛 Mistakes Made

  • None new today — review/release day. Carried-over fixes (overflow-safe backoff, label sorting, only-producer-closes) are logged in their day notes.

❓ Open Questions

🧠 Active Recall (answer without looking)

  1. Q: Give the one-sentence reason each Week 4 layer exists: hexagonal, Redis queue, retries+DLQ, metrics.
AHexagonal keeps the domain testable and infrastructure-swappable; the Redis queue decouples request acceptance from slow processing; retries+backoff+DLQ make processing survive transient failures without looping forever or dropping work; metrics make the running system observable (RED: rate, errors, duration).
  1. Q: Why does at-least-once delivery force idempotent handlers, and how do you make a handler idempotent?
ARetries and reliable-pop mean the same job can be delivered more than once, so a non-idempotent handler would double-apply effects. Make it idempotent by deduping on a stable job ID / idempotency key (e.g. INSERT … ON CONFLICT DO NOTHING, or a processed-set check) so a repeat is a no-op.

🪶 Feynman Reflection

Month 5 turned "I can write Go" into "I can ship a service." I learned the bytes under gRPC, then the middleware/transport around it, then how to arrange code so the business logic doesn't drown in infrastructure, and finally how to make the whole thing resilient, observable, and documented. The capstone is a small but real microservice — and tagging v0.5.0 makes that concrete.

🕳️ Knowledge Gaps

  • Streaming RPCs end-to-end and distributed tracing across the queue boundary — top of Month 6.

✅ Summary

Month 5 done: I can design, build, test, document, and release a gRPC + Redis-queue microservice with hexagonal layering, resilient retries/DLQ, and Prometheus-style metrics. Confidence solidly in the 3–4 band; v0.5.0 tagged.

⏭️ Next Steps / Prep for Tomorrow

Time spent Difficulty Confidence
90 min 🟦⬜⬜⬜⬜ 🟦🟦🟦🟦⬜

Suggested commit: docs(journal): month 5 review + tag v0.5.0 (day 140)