How – The Technical Design
Why “How” Is Where Ideas Become Reality
The “How” is the engine room of the 6Ws. It’s where outcomes and business value are translated into actual systems. This chapter is about implementation strategy, and goes beyond technical diagrams, it's about showing your thinking clearly, walking the reader through your logic, and detailing how your design solves the right problem for the right user.
A great “How” chapter reads like a story: it introduces the actors, describes the conditions, and shows how each piece fits together in a narrative that builds confidence and clarity.
What You Define Here
Component architecture and data flows
System behaviours and responsibilities
Integration touchpoints and interface contracts
Infrastructure responsibilities and constraints
User-centred workflows and implementation sequencing
Failure modes, recovery strategies, observability
Security design embedded from the start
Core data models and persistence logic
Performance tuning and resource cost awareness
Benefits of a Strong “How”
Enables parallel development
Creates confidence across technical and non-technical teams
Reduces costly ambiguity or rework
Supports onboarding and continuity
Forms the backbone of test and deployment planning
Encourages smart use of infrastructure to control operational cost
1. Start with the Story: Walk the Reader Through
Begin by narrating what happens when a user engages with your system. This narrative should follow the actual flow a user might take and explain how each part of the architecture supports that journey.
“When a new consultant logs into the portal via Firebase Auth, their session token is used by the React frontend to securely retrieve their profile via the API gateway. The gateway, running in Kubernetes, proxies the request to a containerised Golang microservice that fetches user data from MySQL via GORM. Access is validated against a policy engine before project data is returned.”
This builds both clarity and credibility. It’s not just showing a diagram, it’s demonstrating your thinking process and user empathy.
2. Architectural Overview
Diagram: System Context Diagram
[ Mobile App (Flutter) ]
|
[ Frontend (React/Next.js) ] --> [ API Gateway ] --> [ Go Microservices (in Containers) ]
|
[ MySQL via GORM ]
|
[ Firebase / Redis / Kafka / 3rd Party APIs ]
Provide a visual that shows:
Entry points (Web, Mobile)
Core services (user, payments, notifications)
Integration points (Auth, messaging, storage)
Kubernetes environment
Separation of internal/public layers
Add callouts for ingress, service meshes, container-to-container security, and observability pipelines (e.g., Loki, Prometheus).
3. Component Breakdown
Template per Component:
Component: [Name]
Type: [Service | Library | Function | External API]
Tech Stack: [e.g. Go, GORM, MySQL, Docker, K8s, Firebase]
Owner: [Team / Domain]
Responsibility: [What it does and why it matters to the user]
Inputs: [HTTP / gRPC / Event]
Outputs: [Event | DB Update | External call]
Security: [TLS / JWT / OAuth / Policy scope]
Performance: [Caching, timeouts, load control]
Failure Handling: [Retry, fallback, circuit breaker]
4. Data Modelling – From First Principles
Design data models around use cases:
Start with user flows → derive entities → validate against outcomes
Prefer normalisation, but allow for denormalised views for performance (e.g., via caching)
Example: Timesheet System
Entities: User, Timesheet, TimesheetEntry, Approval, Project
GORM Mapping (Excerpt):
// Timesheet.go
type Timesheet struct {
ID uint
UserID uint
Status string
SubmittedAt *time.Time
Entries []TimesheetEntry `gorm:"foreignKey:TimesheetID"`
}
Design relational integrity clearly from the outset and embed constraints in the schema. Use field-level encryption where required, and ensure that audit fields (created, updated, deleted) are standardised across tables.
Use Redis to cache frequently accessed objects such as user sessions, permissions, or project metadata to reduce database load. Define cache expiry strategies and graceful fallbacks to database reads.
5. Security by Design
Core Principles:
Auth via Firebase / OAuth2
Enforce least privilege through roles + scopes
Separate internal service mesh from public APIs
Encrypt everything in transit (TLS everywhere)
Apply threat modelling for each component
Include security acceptance criteria in story tickets
Infrastructure Security Tactics:
Container images scanned (Trivy, Snyk)
Network policies in K8s restrict service-to-service traffic
Secret injection via K8s secrets or Vault
SAST/DAST built into CI/CD pipeline
6. Integration Contracts
| System | Purpose | Endpoint / Interface | Security | Observability | Fail Strategy |
|---|---|---|---|---|---|
| Firebase Auth | Identity provider | Token issuance / validation | OAuth2, HTTPS | Audit logs enabled | Block + alert |
| Internal Notification Service | Send emails/SMS | gRPC | mTLS | Prometheus metrics | Retry w/ exponential backoff |
| Stripe | Payment integration | HTTPS webhook + REST | Secret key + IP allowlist | Logs to external SIEM | Dead-letter queue |
7. Infrastructure Blueprint
Cluster: Kubernetes on managed service (e.g., GKE, AKS)
Ingress: Envoy or NGINX ingress controller
Service Mesh: Istio or Linkerd (for security policies and metrics)
Persistence: MySQL with read replicas
Secrets: Vault, sealed-secrets, or K8s Secrets
CI/CD: GitHub Actions or GitLab Pipelines + ArgoCD
Monitoring Stack:
Metrics: Prometheus + Grafana
Logs: Loki / ELK
Traces: OpenTelemetry
Performance Enhancements:
Redis used to reduce frequent DB reads
CDN for static assets (especially in React/Next.js)
Avoid N+1 queries via GORM preloads
Use asynchronous queues (Kafka, NATS) for heavy ops
Rate-limit user-heavy APIs to prevent spikes
Cost-Awareness Tip: Use resource limits and horizontal pod autoscaling to prevent over-provisioning. Design endpoints and workflows to avoid unnecessary compute or memory overhead.
8. Process Flows
Narrate each user journey:
Request begins at Flutter/Next.js frontend
Auth token checked against Firebase
Request routed via API gateway to service
Business logic in Go calls GORM for DB access
Frequently-used data hits Redis cache first
Event emitted to Kafka for async processes
Response returned, observed and logged
Add flow diagrams per core scenario.
9. Design Justification Table
| Choice | Reason | User Impact |
|---|---|---|
| Go + GORM | High performance, strong typing | Faster API response, low latency |
| Flutter | Cross-platform mobile | One codebase, consistent experience |
| MySQL | Reliable relational DB, supports joins | Solid audit trail and reporting |
| Redis Caching | Reduce DB load, faster reads | Instant data load for common actions |
| Containers in K8s | Scalability, isolation, recovery | Faster deploys, safer updates |
| Firebase Auth | Offload identity & security | Faster onboarding, secure access |
10. Summary
A good “How” chapter is like a guided tour of your solution. It's not just a spec, it's a demonstration of engineering empathy. Done well, it:
Builds confidence in stakeholders
Reduces ambiguity for implementers
Highlights robustness and realism
Connects tech to the people who use it
Optimises for performance without over-engineering
Keeps hosting costs in mind without compromising value
Don’t just say what tech you’re using. Say why, say how it fits together, and say how it helps the user.
This is where software design becomes storytelling, and storytelling becomes delivery.
Rhys Morgan
Enterprise Automation Services specializes in AI, automation, SaaS development, and digital transformation. We help businesses across the UK leverage technology to drive growth and efficiency.
