The Castle & The Marketplace: Deconstructing Corporate Networks for Your System Design Interview

Mid Engineer Asked at: FAANG, Unicorns, Enterprise

Q: You're designing a new internal HR portal for a 10,000-person company. It handles sensitive employee data (salaries, reviews). It must be accessible to employees both in-office and working remotely. How do you design the network architecture?

Why this matters: This isn't a networking question; it's a security and trust question disguised as one. Your answer reveals if you think about systems from a first principle of security or just stitch together cloud services you've heard of.

Interview frequency: High. This concept is the invisible foundation of nearly every internal-facing system design question.

❌ The Death Trap

95% of candidates fall into reciting a cloud provider's product catalog. They create a word salad of jargon that shows memorization, not understanding.

"Most people say: 'I'll use an AWS VPC with a public subnet for the web server and a private subnet for the database. I'll put a NAT Gateway in the public subnet so the database can get updates, and an Application Load Balancer to route traffic.'"

This isn't wrong, but it's a hollow blueprint. It answers "what" but completely ignores "why." It's the equivalent of listing ingredients without knowing how to cook.

🔄 The Reframe

What they're really asking: "How do you draw the line between the trusted world and the untrusted world? And how do you enforce that boundary?"

This reveals your understanding of security boundaries, attack surfaces, and the fundamental purpose of a corporate network: to protect valuable assets while still allowing work to be done.

🧠 The Mental Model

Forget subnets and gateways. Think of your company's network as a medieval kingdom. This is the "Castle and Marketplace" model.

1. Build The Castle (Private Network): This is your trusted realm. Inside its walls are the crown jewels—the HR database, internal services. Everything inside uses a private language (private IPs) that makes no sense to the outside world. They can all talk to each other freely.

2. Guard The Gate (Router/Firewall with NAT): The castle has one, heavily-guarded main gate. This is your router. It has a public address (the castle's address on the world map). When someone inside needs to get something from the outside world (like a software update), the gatekeeper (NAT) fetches it for them, never revealing who inside asked for it. No one from the outside can initiate a conversation with someone inside.

3. Set Up The Marketplace (Public Zone/DMZ): If you need to do business with the public (e.g., an e-commerce site), you don't let strangers wander your castle. You build a marketplace just outside the main walls. It's still on your land and protected by your guards, but it's not inside the castle itself. This is your public-facing service zone.

4. Create The Secret Tunnel (VPN): Your trusted knights (employees) need a way to get into the castle when they're abroad. You don't just leave the gate open. You give them a key to a secret, guarded tunnel (the VPN) that lets them securely enter the castle walls and act as if they were inside.

📖 The War Story

Situation: "At my last company, 'TradeCorp,' we had to build a real-time trade settlement dashboard for our finance team. It displayed sensitive client transaction data."

Challenge: "The data was extremely sensitive, subject to financial regulations. It had to be completely isolated from the public internet. However, our finance analysts were distributed globally, working from home."

Stakes: "A breach wasn't just a tech problem; it was an existential threat. It could lead to multi-million dollar fines, loss of our trading license, and a complete collapse of customer trust."

✅ The Answer

My Thinking Process:

"My first thought was, 'This is a crown jewels problem.' I immediately applied the 'Castle and Marketplace' model. The dashboard and its database were the crown jewels, so they had to go deep inside the castle. Public access was forbidden by default."

What I Did:

"First, we defined our 'Castle.' We provisioned a private network space, specifically using the 10.0.0.0/16 address range. The dashboard servers and the database were placed in this private zone. They couldn't be addressed from the public internet, period.

Second, we established the 'Secret Tunnel.' We configured a VPN gateway. Any analyst, no matter where they were, had to connect to the VPN first. Once connected, their laptop was issued a temporary private IP address, effectively placing them 'inside' the castle walls. Only then could they access the dashboard's internal address.

Third, we needed our servers to fetch security patches, which required outbound internet access. So we set up our 'Guarded Gate'—a NAT Gateway. The servers could initiate requests to the outside world through the NAT, but the NAT itself would block any unsolicited incoming traffic. The internal IP of the server was never exposed."

The Outcome:

"The system went live and successfully processed billions in settlements. We underwent two external security audits which specifically praised our network isolation model. More importantly, we had zero security incidents related to this system, and our distributed finance team could operate seamlessly and securely."

What I Learned:

"I learned that network architecture is the physical embodiment of your trust policy. You can talk about security all day, but the IP address ranges and firewall rules are where the promises become reality. A simple, ruthlessly enforced boundary is worth more than a dozen complex, poorly understood security tools."

🎯 The Memorable Hook

"Private IPs are for conversations. Public IPs are for declarations. The goal of a secure network is to have as few declarations as possible."

This frame shows you understand the fundamental purpose of network segmentation. It’s not just about connecting machines; it’s about controlling who can speak, who can listen, and who can start the conversation.

💭 Inevitable Follow-ups

Q: "What if a part of this HR application needed to be public, like a job listings page?"

Be ready: "That's a perfect use case for the 'Marketplace.' I would build a separate, public-facing service for job listings. It would be in a public subnet, get a public IP, and communicate with the internal 'Castle' services only through a highly restricted, authenticated API. It would never have direct database access."

Q: "How does Network Address Translation (NAT) actually work here?"

Be ready: "Think of it as a company's receptionist. An internal employee (private IP) asks the receptionist (NAT) to call a supplier (public IP). The receptionist makes the call using the company's main phone number (public IP). When the supplier calls back, they call the main number, and the receptionist, who remembers who made the original request, forwards the call to the correct employee. The supplier never knows the employee's direct extension."

🔄 Adapt This Framework

If you're junior: Focus on one part of the castle. "I haven't designed a whole corporate network, but on my project, we made sure our database server was in a private network, and only our application server's IP was allowed to talk to it. This protected it from being accessed by any other service."

If you're senior: Talk about managing a kingdom of castles. "The real challenge isn't one VPC; it's managing peering and transit gateways between dozens of them for different departments, each with their own security policies. The goal is to create a 'federation of trusted castles' without creating a chaotic free-for-all."

If you lack this experience: Lead with the mental model. "Theoretically, I'd approach this using the 'Castle and Marketplace' principle. My first priority would be to define what needs to be in the castle—the most secure zone—and build outwards from there, assuming zero trust at every boundary."