I recently set out to build an E-commerce platform using a Microservice Architecture. With a decent level of experience, I figured I could move fast: define a high-level plan, get help refining it, and dive straight into implementation.
To speed things up, I shared my initial ideas—workflow, database schema, and API routes—with GPT, got a refined version, and started building based on that.
In hindsight, this approach taught me a lesson I didn’t expect to learn at this stage of my career: no matter how experienced you are, skipping proper planning will come back to haunt you.
Where Things Started to Fall Apart
After jumping into implementation, I began to realize that the schema I was working with had several gaps. Things looked good at first glance, but I hadn’t accounted for:
- Edge cases
- Data integrity constraints
- API request/response inconsistencies
- System-wide failure handling
As I began to handle these situations, I needed to redesign the schema multiple times, and every time I did, it started breaking the previously built routes and services. I was using Bruno to test the APIs, and it became clear that things weren’t as stable as I thought.
The Domino Effect of Midway Changes
Once the BFF (Backend for Frontend) layer was complete, I moved on to building the frontend. That’s when I hit another wall.
New frontend requirements led to additional changes in the schema and logic, which again caused issues in the routes and services I had already implemented. The lack of a stable contract between services and layers became a real bottleneck.
The deeper I went, the more everything started feeling like a Jenga tower—one change, and things would start to collapse.
Key Lessons Learned
This experience forced me to take a step back and reflect. Here's what I took away from this:
- 🧠 Plan extensively before implementation: Even if it delays coding by a week, it's worth it.
- 🧩 Model your schema based on actual business logic, not assumptions or third-party suggestions.
- 🔄 Version and document your APIs early to prevent regression from breaking existing services.
- 🧪 Validate your design against use cases before committing to it—mock flows, simulate errors, think long-term.
- 🛑 Don’t depend entirely on tools (or even AI) for architectural decisions—they're great support systems, not decision-makers.
The Role of an SDE II Isn't Just to Build—It's to Architect
At the SDE II level, you're expected to think beyond writing clean code. You're responsible for:
- System design decisions
- Long-term maintainability
- Collaboration between services
- Edge case handling
- Ensuring that your implementation scales with the product
This project reminded me that being effective means slowing down when it matters. Rushing into code may feel productive at first, but without proper planning, it creates long-term technical debt.
Final Thoughts
I still love building things fast, but now I do it differently.
- Spend more time on schema modeling
- Write down API contracts
- Think through edge cases and fallback scenarios
- Collaborate with teammates early to identify potential blockers
If you're at a similar stage in your engineering journey—or even just starting out—treat planning as an engineering discipline. The time you spend upfront will pay off tenfold during implementation.
Thanks for reading. If you've had a similar experience (or a completely different one), I’d love to hear your thoughts in the comments.
Top comments (0)