Did the FedEx senior software engineer system design round as part of their full virtual onsite earlier this year. Sharing notes because I couldn't find anything specific when I was prepping.
The format: 45 minutes, one interviewer (a principal engineer on the logistics platform team). Collaborative whiteboard via Miro, which was fine.
The prompt I got: design a real-time package tracking system that scales to handle several million daily scans across 5,000+ facilities. Which, credit where it's due, is actually a pretty interesting problem domain given that it's FedEx's literal core business.
Things they cared about: How you handle write-heavy load. Lots of package scan events coming in simultaneously from facilities. They wanted to talk about Kafka or similar event streaming, not just a naive DB write per scan. Read latency for the customer-facing API. If millions of people are hitting "where's my package" at the same time, what's your caching strategy. Redis came up naturally. Eventual consistency trade-offs. This was the interesting part. They probed whether you understand why strong consistency might be too expensive here and when eventual consistency is acceptable for a user checking tracking status. Database partitioning. Tracking number as a partition key, predictable access patterns. They seemed to want to see you think about scale-out from the start rather than treating it as an afterthought.
What they didn't push hard on: fancy distributed systems theory. No deep dive on Paxos or Raft. More practical than academic.
I'd put the difficulty at "senior IC at a mid-tier tech company" level. Not a FAANG staff-level deep dive, but they clearly want someone who knows real distributed systems tradeoffs, not just someone who can draw boxes on a diagram.
Prep I'd recommend: Designing Data-Intensive Applications chapters on replication and partitioning, and one good run-through of a high-write-throughput event system (tracking, ride-sharing, etc.).