Project Overview: From Concept to Cloud

Welcome to the engineering deep dives of LZStock.

Project Motivation

The purpose of this series is not to preach "perfect" solutions. In modern software engineering, perfection is an illusion; everything is a trade-off. This series documents the raw thinking process, the lessons learned, and the architectural decisions made while building LZStock—a distributed financial dashboard system. It captures both the successful scaling strategies and the pitfalls encountered during development.

Target Audience

• For Fellow Developers & Architects: I hope these articles provide practical, battle-tested references for applying Domain-Driven Design (DDD), Clean Architecture, and Cloud-Native patterns in real-world Go projects.
• For Interviewers & Engineering Leaders: I aim to demonstrate not just my coding capabilities, but my deep understanding of system design, infrastructure scalability, and the pragmatic compromises required to deliver production-ready software.

The Philosophy

LZStock represents a comprehensive, end-to-end engineering endeavor. It is a transition from isolated coding to Enterprise-Level System Architecture with CI/CD. The philosophy here is simple: Design it, Build it, Break it, Fix it, Scale it, and Document the Journey.

What to Expect

Reading a massive technical portfolio at once is exhausting. Therefore, I have structured this series from the macro (System Boundaries) down to the micro (Database Indexes). The evolution of LZStock is broken down into 5 architectural layers.

Loading...

Feel free to jump directly into any layer that interests you:

I chose Golang as the primary development language. Golang's type alias mechanism is suitable for DDD, as it allows defining rich domain types without the performance or memory footprint of creating complex structs.

---

Domain-Driven Design or DDD

How do we prevent a microservices architecture from becoming a fragile distributed monolith?

• Strategic DDD: Bounded Contexts and Context Mapping

How do we utilize Go's type system to make invalid business states impossible to represent?

• Tactical DDD: Enforcing Invariants with Domain Objects

---

Back-end Development

• Algorithm and Datastructure
  • Auto-complete Search Tree
• Concurrency
  • Price Streaming Engine
    • Deep Dive: Load Testing the Streaming Engine to 5k+ Users - Summary
  • Worker Pools: Concurrency & Backpressure
• Error Handling
  • The 3-Tier Error Propagation Chain
• Use-cases and Controllers
  • DDD with Clean Architecture
  • System Entrypoints: Managing gRPC, Events, and Cron Jobs
• API Design and Versioning:
  • API Gateway
  • Real-Time Streaming with Errgroup
  • CORS middleware
  • Authentication middleware
• Testing
  • Testing Boundaries

Database Design and Optimization

• SQL Plan and Index
  • Database Profiling: Proving Performance with EXPLAIN ANALYZE
  • Beyond B-Trees: Advanced PostgreSQL Indexing Strategies
• Data Query
  • Pagination Strategies
  • Eradicating the ORM N+1 Problem
• Redis Optimization
  • Redis Lua script for atomic operations
• Database Selection
  • Favor PostgreSQL over MySQL
• Partitioning
  • Partitioning and Sharding Strategy

Front-end Development

• Client-Side Architecture: Building a High-Performance SPA without Next.js

---

Fault Tolerance

• Retry Strategies: Exponential Backoff & Jitter in Distributed Systems
• Self-Healing Microservices: Service Registry via NATS KV
• Pod Failure Recovery

High Availability and Scalability

• Elastic Scalability: Beating Scaling Latency with KEDA Pre-warming
• Stateful Service Scaling

Networking and Protocols

• Asynchronous Communication
  • Event-Driven Resilience: At-Least-Once Delivery with NATS JetStream
• Synchronous Communication
  • Inter-Service Communication

---

CI/CD, Cloud and DevOps

• Path to Production: CircleCI, Terraform, and GKE Deployment

Monitoring and Observability

• Health Check and Liveness Probe
  • Observability & Liveness: Concurrent Probing and Pprof Profiling
• Logging
  • Structured logging