Why I'm Building a Distributed Systems Portfolio in Public

Proprietary code taught me a lot. It didn’t leave me much to show. #

I’ve worked with large distributed systems in my career but they have always been proprietary. When someone asks “can I see something you’ve built?”, the honest answer has been “not really”.

So I’m fixing it by building in public.

What I’m building #

The first repo is StreamShop a fictional e-commerce platform designed as a local-first distributed systems showcase. Customers browse a product catalog, place orders, and trigger an event pipeline that feeds real-time analytics. It’s a coherent domain, not a bag of unrelated demos.

The stack is deliberately realistic:

  • Polyglot microservices
    • Go for orders
    • Node for catalog
    • Python for analytics
    • Rust for async event processing
  • Multiple data stores
    • PostgreSQL for transactions
    • MongoDB for flexible product documents
    • ClickHouse for OLAP
    • Redis for caching
    • MinIO for object storage
  • Infrastructure as a first-class concern
    • Traefik as an API gateway
    • nginx for load balancing
    • Redpanda (Kafka-compatible) for event streaming
  • Full observability
    • OpenTelemetry
    • Jaeger
    • Prometheus
    • Grafana
  • Everything runs locally with docker compose up

What I’m trying to demonstrate #

This isn’t about proving I can write four languages. It’s about showing that I understand:

  • Service boundaries
    • Each service owns a clear write path to its datastore
  • Sync vs async
    • Orders are written transactionally
    • Downstream processing happens via events
  • Store selection
    • Relational for orders
    • Document for catalog flexibility
    • Columnar for analytics
  • Operational thinking
    • Health checks
    • Consumer lag
    • Cache hit ratios
    • Distributed traces
  • Documented trade-offs
    • ADRs explaining why Compose over k8s
    • Redpanda over Kafka
    • and similar choices
  • The docs site (Docusaurus) includes
    • Architecture overviews
    • Data-flow walkthroughs
    • Runbooks
    • and ADRs alongside the code

In my experience, that’s what separates a portfolio project from a toy demo.

What this isn’t #

I’m being deliberate about scope. This is local-first interview/demo scale app to showcase the logical parts of a distributed system.