Can You Draw Your Backend System End to End?

Look at backend interview questions one by one and they barely connect. System architecture, MySQL engines, Linux package managers, SSH tunneling, ERD, Redis, deployment, WAS optimization, PayPal integration, secure coding. The surface area is huge.

But once you sit through a few interviews, you start to see it. The questions vary, but what they're filtering for is almost always the same.

Can you draw the system you built on a single page, and then open up one of the boxes in detail?

This post organizes the 13 areas I see most often through that lens. Not as a list of model answers, but as a checklist for revisiting your own experience.

Draw the Whole System on One Page#

The first interview question is almost always similar:

"Walk me through the system architecture of your last project."

What this filters for is simple: can you draw the system you actually touched on a single page? If you can, every follow-up has traction. If you can't, the rest of the interview goes nowhere.

A good architecture diagram has three things.

1. Components and responsibilities — what each of client, load balancer, WAS, DB, cache, and external APIs actually does
2. Inter-component communication — HTTP/HTTPS, gRPC, JDBC, queues — what protocol carries what
3. Failure paths — where it falls back when a component dies, and what data is lost

Deployment is really an extension of this picture. "Where do we put it?" (EC2, ECS, EKS, Lambda, etc.), "how do we swap it out without downtime?" (blue/green, canary, rolling), "how do we roll back?" — those three questions are the heart of any deployment question.

WAS setup and tuning is just zooming into one box of that diagram. Whether it's Tomcat or Spring Boot's embedded server, the core is the same.

• Thread pool size — how many concurrent requests it can handle, tuned to CPU and I/O profile
• Connection pool size — must align with the DB's capacity (WAS × instance count ≤ DB max_connections)
• Timeouts — set distinct values for response, DB, and external calls
• JVM options — heap size and GC algorithm (G1 is the usual default; for large heaps, JDK 21+'s Generational ZGC is effectively the standard recommendation)

How Do You Handle Data?#

The data area folds three things together: DB choice, schema design, and caching.

If You Used MySQL, Which Engine?#

"I've used MySQL" isn't enough. The storage engine you used is the real signal.

In practice, InnoDB is the default everywhere. So the deeper follow-up is "what isolation level did you run?" You should be able to talk about the difference between REPEATABLE READ (the default) and READ COMMITTED, and how gap locks contribute to deadlocks.

What Do You Look at When Drawing an ERD?#

The line between someone who designs an ERD and someone who transcribes one runs through these:

• Intent of normalization and denormalization — it's not about reciting 1NF/2NF/3NF; it's about deciding where to normalize and where to deliberately denormalize
• Choosing keys with indexes in mind — are frequently queried columns part of the PK/UK/indexes, and is the composite index ordered with high-cardinality columns first
• Foreign key policy — ON DELETE CASCADE vs RESTRICT, or does the application handle it
• Designing for change — separating columns that change often into their own tables makes migrations easier

Redis (or Valkey): Self-Hosted or Managed?#

After Redis's 2024 license change (SSPL/RSALv2), the Linux Foundation–backed Valkey fork has become the mainstream open-source alternative. AWS ElastiCache and MemoryDB now offer Valkey as a default option. Whichever you used, the question is the same:

"Did you stand it up yourself, or use a managed service?"

This matters because it separates operational depth from surface-level use.

• Self-hosted — Which mode? Master-replica, Sentinel (HA), or Cluster (sharding)? How did you configure memory policy (maxmemory-policy)?
• Managed (ElastiCache, MemoryDB, etc.) — lower ops burden, but you should understand the cost model and constraints (parameter group limits, cluster mode differences)

It also helps to think about caching itself. What do you cache (read-heavy, low-write data), what's your expiration policy (TTL, LRU), what happens on a cache miss (thundering herd mitigation). The answers get deeper.

Get Your Hands on the Infrastructure#

Linux, package management, and SSH usually come bundled. The interviewer is really asking: can you actually work in a terminal?

Which Linux You Used = Which Package Manager You Know#

The same package can have a different name and dependency tree across distros. apt gives you nginx, while on Alpine you often need nginx plus ca-certificates explicitly.

"I've Published a Package" Is Surprisingly Valuable#

Whether it's an internal private registry or npm/PyPI/Maven Central, having published a package once shows several things:

• You understand semantic versioning — what major.minor.patch actually changes
• You can manage dependencies explicitly — peer/dev/optional distinctions
• You know how metadata (README, license, keywords) affects discoverability

Build one library, ship it even just internally, and you start to see things you couldn't see as a pure consumer of libraries.

SSH Keys and Tunneling#

• Generate keys with ssh-keygen -t ed25519 -C "email" — shorter and faster than RSA
• Register the public key by appending it as a single line to the server's ~/.ssh/authorized_keys
• Permissions matter: ~/.ssh is 700, authorized_keys is 600

Tunneling is the standard way to safely reach internal resources that are walled off from the outside:

# local 13306 → via bastion → RDS 3306
ssh -L 13306:rds.internal:3306 user@bastion.example.com

Open this up and your local MySQL client just connects to localhost:13306. Useful when you need to poke at a production DB briefly without spinning up a VPN.

Think About Security at the Code Level#

Secure coding and payment integration are really one cluster. They're both about a healthy suspicion toward everything that touches the outside.

The Big Four of Secure Coding#

1. Always validate input — SQL injection: parameter binding. XSS: escape on output.
2. Separate authentication and authorization — "who you are" and "what you can do" are different layers
3. Keep secrets out of code — use environment variables or a secrets manager (AWS Secrets Manager, Vault)
4. Never log sensitive data — card numbers, tokens, personal data should be masked

What Matters Most in Integrating External Payments Like PayPal#

It's less about features and more about state and idempotency.

• Define the payment state machine clearly — encode flows like PENDING → APPROVED → CAPTURED → REFUNDED identically in code and DB
• Verify webhooks (IPN) — confirm PayPal's signature, and process events with an idempotency key so retries don't double-apply
• Transactional consistency for refunds and cancellations — use compensating transactions or the outbox pattern to keep external API calls and your DB updates in sync
• Don't store payment information directly — keep card numbers only as tokens (per PCI DSS 4.0)

This is where the gap between "code that works" and "code that survives in production" is widest.

It All Converges on One Question#

Thirteen areas in, the conclusion is the same as the opening.

Can you draw the system you touched on a single page, and open each box one level deeper?

Interview prep isn't "memorize the four MySQL isolation levels." It's drawing the system you actually built one more time, and asking yourself "why did I choose this here?" for every box. Then when the same question lands, what comes out is your own answer, not a model answer.

The non-technical questions at the end are really the same shape. "What do you want to get good at?" "Where do you see yourself in three years?" "Are you interviewing anywhere else?" — these are asking whether you've ever drawn the architecture diagram of your own career. People who can put their direction on a single page answer fast.

Tech or career, it's the same muscle. The habit of drawing a single page, and opening one of its boxes.

Spring is a time for rebirth and the fulfilment of new life.

— Byron Pulsifer