Cloud-Native Commerce: Why Architecture Matters
How we built Crowdstart as a cloud-native platform from day one, and why this matters for commerce.
Five months into building Crowdstart, we have learned that commerce platforms succeed or fail based on architectural decisions made early. Here is why we chose cloud-native from day one.
The Legacy Problem
Traditional commerce platforms were built for a different era. They assume:
- Predictable, steady traffic patterns
- Single-region deployment
- Monolithic application architecture
- Vertical scaling through bigger servers
Crowdfunding campaigns violate every assumption. Traffic spikes 100x during launch windows. Backers span the globe. Features must evolve rapidly. Scale must be elastic.
Our Approach
Crowdstart runs on cloud infrastructure with these principles:
Stateless Services
Every service instance is identical and disposable. State lives in managed databases and caches. We can scale any service tier independently based on load.
Event-Driven Architecture
Order placement, payment processing, and fulfillment operate as independent event streams. A surge in orders does not block payment confirmations. Fulfillment processes at its own pace.
Multi-Region by Default
Customer data lives close to customers. A creator in Tokyo serving backers in Germany experiences the same latency as one serving local customers.
Infrastructure as Code
Every environment is reproducible from configuration. Development mirrors production. Deployments are automated and reversible.
Results
During a recent campaign launch:
- 47,000 concurrent users at peak
- Sub-200ms response times maintained
- Zero downtime during 72-hour surge
- Cost scaled linearly with traffic
Technical Choices
We standardized on:
- Containers for service packaging
- Managed databases for operational simplicity
- CDN-first static asset delivery
- Queue-based async processing
Lessons Learned
- Managed services are worth the premium - Operational burden compounds faster than expected
- Observability is not optional - You cannot optimize what you cannot measure
- Design for failure - Assume any component can fail; the system must continue
Cloud-native is not a buzzword. It is a practical approach to building systems that match the reality of modern commerce.
Zach Kelling is the founder of Hanzo Industries.
Read more
The router is the registry
Hanzo Cloud has no checked-in OpenAPI file. The live route table is the source, projected three ways, and a bijection test fails the build if any projection drifts. 1,362 operations across 963 paths, generated per process at request time.
LLM Infrastructure: Running AI at Scale
How we built infrastructure to serve billions of LLM requests for commerce applications.
Building Our ML Framework
Why we built a custom ML framework and what we learned along the way.