↓Skip to main content
  1. tech-posts/

Creating an Architecture Diagram for Global EC Site

·5 mins
Tech E-Commerce Aws Architecture Job Hunting
Table of Contents

Overview #

A few weeks ago, I applied for a Security Consultant role at a tech company in Japan. As part of the interview process, candidates were asked to design an architecture diagram for a global e-commerce (EC) site and present it during the interview. In this post, I’ll share the architecture I designed—built using AWS services.

The Task: Draw an Architecture Diagram #

The prompt was intentionally vague. The only instruction was:

“Draw an architecture diagram for a global e-commerce site. Draw the assumed architecture while being mindful of non-functional requirements.”

They also shared the criteria used to evaluate candidates:

  • Ability to design infrastructure for large-scale systems
  • Knowledge of infrastructure components such as networks, data stores, and web servers
  • Awareness of non-functional requirements in system design
  • Logical reasoning behind architectural decisions
  • Security design to protect operational systems

My Approach #

For an open-ended task like this, a minimalist design might technically suffice—but in an interview context, the architecture should be realistic, modern, and impressive. I aimed to design an architecture that is:

  • Flexible – simple at a glance, but can be extended to handle more complex cases
  • Modern – based on current best practices and patterns
  • Secure – because this is a Security Consultant position

Understanding Non-Functional Requirements #

I found the term “non-functional requirements” (非機能要件 in Japanese) particularly interesting. While I was already familiar with the distinction between requirements and specifications, I am not familiar with this classification before.

What Are Non-Functional Requirements? #

Non-functional requirements define how a system should perform, rather than what it should do. They can be qualitative or quantitative and are often driven by technical or business constraints. For a global EC site, examples might include:

  • Must support users in Japan, the US, and the EU
  • All product pages should load within 2 seconds
  • Must scale to 10x normal traffic during promotional events
  • Recovery Time Objective (RTO) of 2 hours
  • End-to-end encryption (e.g., AES-256) for payment data
  • GDPR compliance
  • Monthly operating cost under ¥100,000

Functional vs. Non-Functional #

In contrast, functional requirements (機能要件 in Japanese) focus on what a system should do. Here are some examples of functional requirements:

  • Support multiple payment methods (e.g., credit card, PayPal)
  • Users can add items to a shopping cart
  • Display product reviews
  • Users can post and delete comments on products

Breaking Down the Requirements #

Based on the task and evaluation criteria, I outlined the following core non-functional requirements:

  • Follow a 3-layer architecture (presentation, application logic, storage)
  • Scalable across all layers
  • Global user coverage
  • Microservices-based architecture for agility and third-party integration
  • Multi-region deployment for disaster recovery
  • Robust security practices

In the last point above, the “security” is a broad term so I broke it down into concrete practices:

  • Network Security
    • Host app components in private subnets, with only the load balancer in the public subnet
    • Prevent microservices from having direct internet access
    • Enable VPC Flow Logs for network traffic auditing
  • Application & API Security
    • Use Web Application Firewall (WAF) to mitigate attacks like SQL injection and cross site scripting (XSS)
    • Implement DDoS protection (e.g., using AWS Shield Advanced)
    • Use a centralized API gateway for authentication and access control
    • Apply rate limiting and throttling at the API layer
    • Track vulnerabilities across VMs, containers, and dependencies
    • Encrypt all inter-service communication
  • Data Protection
    • Encrypt all databases and application logs at rest
    • Enforce least-privilege access via IAM and Service Control Policies (SCPs)
    • Apply regional data residency controls where applicable
  • Session Management
    • Secure session storage with proper timeouts
    • Encrypt and sign session cookies
    • Use encrypted data stores for session persistence
  • AWS-Specific Best Practices
    • Enable AWS CloudTrail for logging API activity
    • Use AWS Config for compliance checks
    • Aggregate findings in AWS Security Hub

The Architecture Diagram #

Here’s the AWS-based architecture I proposed (please open the image in new tab to see it larger):

aws-global-ec-site-architecture-diagram

Key Components:

  • Networking
    • Enable VPC Flow Logs for network traffic monitoring.
    • Deploy AWS WAF in front of CloudFront (global deployment) and ALB (regional deployment).
  • Compute
    • In the architecture above, the front-end is implemented with EC2 auto-scaling group. This is not really a hard requirement and can be replaced with ECS Fargate (depending on the team needs). I just want to show the possibility of mixing more traditional compute architecture with microservices.
    • Application logic layer (microservices) are implemented with container-based compute (ECS Fargate in the architecture above, but we can replace it with EKS as well).
  • Global coverage
    • Use CloudFront CDN (Content Delivery Network) to cache both static (.js, .html, .css) and dynamic content for better latency.
  • Storage & Database
    • Aurora: Multi-AZ replication, with optional cross-region async replication for disaster resiliency.
    • DynamoDB: setup the Global Table replication. This enables async cross-region replication.
  • Multi-Region Strategy can be implemented using either of these approaches. The diagram above shows pilot-light approach.
    • pilot-light: only the database is on standby in the second region, other compute resources will be created later when the first region is unhealthy.
    • active-active: have all resources to be created in two regions. This setup requires careful DB coordination.
  • Other Features
    • Use AWS Personalize for AI-powered product recommendations.
  • Not shown in the diagram (due to space):
    • AWS Shield: prevent DDoS attack
    • Amazon Inspector: to check security vulnerability in EC2 or ECR containers
    • CloudTrail: AWS API call logging
    • Amazon Config: compliance monitoring
    • AWS Security Hub: centralized security findings
    • Secure session management and caching (potentially via DynamoDB)

Closing Remarks #

I believe the architecture above is solid, though not exhaustive. Architecture diagrams are great conversation starters—but they rarely capture every design decision.

Also, please note that I’ve never designed or operated a global e-commerce platform in production, so this is a learning experience for me too. Actually, I got a lot of inspiration from this LinkedIn post. Anyway, if you have suggestions or feedback, I’d love to hear from you.

Thanks for reading. I hope this post inspires your own architecture journey as well 😄