You’re launching your first startup… Well, Congrats!
Whether it’s a SaaS invoicing tool, an e-commerce shop for handmade goods, or a new social app, you’ll quickly hit a truth: system design is your blueprint.
Done right, it makes your app boringly reliable. Done wrong, you’ll spend more time firefighting than building features.
This post is based on Sean Goedecke’s excellent piece on system design, reshaped with a founder’s lens: lean, practical, and ready for bootstrapped growth.
Good vs. Bad Design
- Good design: Reliable. Invisible. Like the office coffee machine that “just works.”
- Bad design: Fancy, flashy, fragile. The espresso machine that breaks down weekly.
Always start simple:
- One database.
- One core service.
- Incremental features as you grow.
Example: Airbnb began with air mattresses and a basic site—no global maps, no recommendation engines. Complexity came later.
Rule to tattoo on your desk (or any other spot):
A complex system that works → Always grows from a simple one that works.
Keep State Minimal
State = what your app remembers (users, orders). Stateless = things it calculates on the fly (like generating a PDF preview).
Why minimize? State breaks. Bad data costs you nights and weekends.
- Centralized state. One service owns inventory, orders, or payments.
- Everyone else calls it via APIs.
Example: Shopify routed everything through one “store service” early on. That made inventory and sales predictable.
Scatter state across microservices?
Well, you’ve created chaos.
Databases: Start Solid
- Use PostgreSQL (or MySQL) – In many cases, you do want the flexability of tabular data.
- Design tables that are human-readable.
- Avoid the “dump-everything-in-JSON” trap.
Quick wins:
- Index your most common lookups. Monitor the DB queries and adjust indexes when there is a new need.
- Use JOINs, not N+1 queries.
- Add replicas once traffic grows.
Example: Stripe did this well—fast lookups with indexed charge IDs.
You don’t need Stripe’s scale yet, but you can copy their discipline.
Background Jobs Save UX
Users hate waiting. Anything >300ms? Offload.
- Generate invoices, send reminders, process uploads → queue them.
- Redis or a simple job runner works.
Example: Dropbox uploads files in the background. You should, too.
Tip: For long delays (e.g., “email in 30 days”), store jobs in your DB—not Memory. The Memory will ‘forget it’ crashes.
Caching: Don’t Overdo It
Cache is like caffeine—useful, but addictive and dangerous.
- First: Optimize your queries.
- Then: Cache expensive or external calls.
Examples:
- Cache product prices from a supplier API every 10 minutes.
- Cache popular searches (“handmade earrings”).
Big caches?
Store them in S3 and serve directly.
Events: Loose Coupling
Events are great—but keep them simple.
- Use direct API calls for critical paths.
- Use events for “nice to have” flows (emails, notifications).
Example: New user signup → fire events for welcome email + profile setup.
Core registration stays clean.
Push vs. Pull
- Pull = client asks. Simple, but repetitive. In scale, it won’t be productive to do it.
- Push = server updates clients when things change. More efficient.
Example: Slack pushes messages. Your invoicing app should push payment updates.
Stop making users hit refresh.
Hot Paths
Find your money routes.
- E-commerce → Add to Cart → Checkout.
- SaaS → Signup → First invoice.
Make these flows bulletproof, fast, and heavily monitored (with lots of logs everywhere).
Amazon obsesses over checkout speed.
You should too.
Safety Nets
Systems fail. Plan for it.
- Kill-switches: Turn off broken features quickly.
- Retries + Circuit Breakers: Avoid hammering a dead service.
- Idempotency keys: Billing ops must never double-charge.
Example: Netflix runs chaos experiments. You don’t need to, but you do need feature flags.
Final Thoughts
System design isn’t about shiny tech. It’s about boring reliability.
- Use what your cloud provider already gives you (queues, caches, DBs).
- Keep it simple.
- Add complexity only when you must.
Get the basics right, and you’ll spend more time with customers—not debugging at 2am.
🚴♂️ Same as endurance rides: pace yourself, keep things steady, and avoid blowing up early.
Discover more from Ido Green
Subscribe to get the latest posts sent to your email.
Ido Green 