SAP System Design Interview Questions
- Tell SAP's two design rounds apart: enterprise-tilted high-level design, and low-level OOP modeling with patterns
- Prep a scalable REST API and database design, with multi-tenancy, GDPR, and HANA as a plus on cloud and BTP teams
- Treat the patterns-and-UML round as first-class, since it catches candidates who drilled only distributed systems
Start with the recalibration most candidates need. At the web-scale companies, "system design" means one round where you take a consumer app to a billion users, and the whole game is traffic, sharding, and fan-out. SAP's design bar is lighter on raw scale and split across two different muscles. One conversation is a high-level design round in the familiar register: sketch the services and data stores that make a system work. It's pulled toward the enterprise software SAP ships, though: a scalable REST API, a sensible database schema, and how the whole thing behaves under load. The other is a low-level design round that lives on object-oriented modeling and design patterns, where you turn a fuzzy prompt into a clean set of classes and defend the abstractions.
Neither round rewards the FAANG reflex of reaching straight for Kafka and a global cache. What recurs across candidate accounts is more grounded. One is "design a Tiny URL, walk the HLD and the database design, and handle a lot of requests." Another is "design an API that can handle N concurrent requests," with rate limiting and load balancing named as the follow-ups. On the low-level side: "here is Association, Aggregation, and Composition, now draw the UML for a file system." The prompts are buildable, the depth scales with your level, and the interviewer wants clean, defensible reasoning over a memorized reference architecture.
The design-patterns and OOP-modeling round is the one candidates under-prepare, and it is a genuine SAP signature. People arrive drilled on load balancers and consistency models. Then they're asked to model a file system with the right relationships, design a parking lot or a vending machine as clean classes, or explain where Singleton, Factory, and Observer belong. Reports describe a heavy focus on the creational patterns and, pointedly, applying them to a real scenario rather than reciting the definition. It is not a warm-up bolted onto coding. Treat the low-level design and patterns surface as first-class, because a candidate strong on distributed systems can still lose the loop here.
Two design surfaces
SAP does not run one fixed design round. The exact packaging is team-owned and varies by level, geography, and role, so treat the map below as the terrain rather than a script. What holds across accounts is the two-headed shape. One is a high-level design conversation with an enterprise lens, the other a low-level modeling-and-patterns conversation. They're often folded into the same technical round instead of getting separate slots. The pieces tend to sit like this.
- High-level design: Scalable API and database design, enterprise lens. The recurring prompts are buildable and data-shaped: a Tiny URL with its schema and request handling, or an API that serves N concurrent requests (rate limiting, load balancing, horizontal scaling, queueing). Others are a news feed, a Netflix-style system, and "how does a REST request actually get routed." The interviewer usually wants the database design as much as the boxes.
- Low-level design and patterns: OOP modeling, UML, creational patterns. A distinct seam that catches the unprepared. Draw the UML for a file system using Association, Aggregation, and Composition, and model a parking lot or a vending machine as clean classes. Place design patterns in a real scenario, with a reported heavy focus on the creational family (Singleton, Factory) plus Observer and Strategy.
- The enterprise buzzwords: Multi-tenancy, GDPR, HANA, OData, BTP. For cloud and BTP teams, expect the design to touch multi-tenant data isolation, GDPR-style data deletion, SAP HANA as an in-memory column store, and OData. These are a plus that signals fit rather than a universal gate, and they are less first-hand than the core API-and-DB prompts, so treat them as a bonus lens, not the whole round.
- Level sets the depth: Lighter early, deeper for senior and T3+. Early-career and campus loops keep design light, sometimes only as a follow-up to coding. Experienced-hire loops (T2 and above on the T1 to T5 ladder) carry a real design block, commonly a Java-plus-HLD round. They expect you to drive scalability, failure handling, and trade-offs unprompted rather than waiting to be pulled there.
The high-level design round
This round looks like design elsewhere, take an under-specified prompt, clarify it, and sketch the services, data stores, and flows, but the prompts and the grading lean toward enterprise software. You are as likely to be asked for the database schema and how a REST request is routed as for the request-per-second math. Candidate accounts name a Tiny URL with full HLD and database design, and an API built to handle N concurrent requests. They also name a news-feed or Netflix-style system, and model-plus-API design for something as concrete as saving and fetching student records. Whatever the prompt, justify each choice out loud; the interviewer guides toward the better answer and cares about the reasoning more than the diagram.
Database design is half the round
SQL and schema design are a first-class surface at SAP, and they show up inside the design round too. Be ready to lay out the tables, choose keys and indexes, and defend a normalization or denormalization call. When a prompt says "and the database design," it means it: a design that hand-waves the data model reads as incomplete no matter how clean the service diagram is.
Scale through the standard levers, sized honestly
The N-concurrent-requests prompt is really a checklist made visible: rate limiting, load balancing, horizontal scaling, and queue-based request handling. Name those levers, then say which the problem needs and why. SAP's systems serve enterprise load, steady and contractual rather than viral, so reasoning about sustained throughput and back-pressure lands better than planning for a consumer spike.
Know how the request flows
Interviewers probe the internals under the boxes: how a REST API routes a request and maps it to a handler, how microservices communicate, and why you chose a given datastore. One account was pressed on the internal working of request mapping until a surface answer ran out. Being able to drop from the architecture into the mechanism is what separates a strong high-level answer from a plausible-looking one.
The enterprise lens, where it fits
On cloud and BTP teams, tie the design to enterprise concerns. Multi-tenant isolation keeps one customer's data from leaking into another's. Add GDPR-style deletion and data-retention paths, and SAP HANA's in-memory column store or OData where they genuinely help. Reach for these when the prompt invites them. A well-placed multi-tenancy point signals fit; a forced one signals buzzword matching.
The SAP angleThe low-level design and design-patterns round
This surface asks a narrower question well: can you turn a fuzzy prompt into a small, clean set of classes and interfaces, and can you name where a design pattern earns its place. The prompts are concrete and object-shaped: model a file system and draw its UML, design a parking lot or a vending machine, sketch the classes for a booking or order flow. Grading skips throughput and asks whether the design reads like something a team could own and extend for years, and whether you understand the relationships and patterns you reach for instead of reciting them.
Model the domain and its relationships first
The file-system prompt is explicitly a test of Association, Aggregation, and Composition: which objects merely reference each other, which own a shared part, and which own a part that dies with the whole. Name the entities and their responsibilities, then draw the relationships deliberately. Getting Aggregation versus Composition right on a file, a folder, and their contents is precisely the judgment this prompt is checking.
Design patterns, applied
Reports describe a heavy focus on the creational patterns, Singleton and Factory foremost, with Observer and Strategy close behind, and a consistent demand that you place them in a real scenario. A Factory that removes a real construction branch earns points; a Singleton named without a reason to be global does not. Know when a pattern removes a seam and when plain code is the honest answer.
Clean, readable classes over clever ones
The same instinct that runs through SAP's coding rounds runs here: interviewers repeatedly say they want clean, readable code over clever tricks. Favor composition over deep inheritance, keep each class to one responsibility, encapsulate state, and name things honestly. A design that a new engineer could read and extend beats a compact, clever one that only its author understands.
Design for the change you can see coming
Low-level prompts invite an extension: a new vehicle type in the parking lot, a new file type, a new payment method. The question is whether that change lands in one new class or ripples through the ones you already wrote. Draw the interface where the next requirement will slot in, and say out loud where you left the seam. Open-closed reasoning is what turns a passable model into a strong one.
The SAP angleHow this differs from a web-scale FAANG round
If your mental model of a design interview is a single ninety-minute round where you scale a photo feed to a billion users, recalibrate. That round has a cousin at SAP in the high-level prompts, but its constraints pull in a different direction. And half the design bar lives in a low-level modeling round that a pure web-scale plan never touches. The contrast below is the shift to make.
A pure web-scale FAANG round
- One design round, almost always high-level and distributed
- The headline constraint is traffic: requests per second, fan-out, a viral spike
- Prompts are consumer products: a feed, a messenger, a video platform, a ride app
- The database is often a box labeled "NoSQL"; schema detail is secondary
- Clean OOP modeling and design patterns, if tested at all, are a small coding aside
An SAP design loop
- Two surfaces: an enterprise high-level round and a low-level modeling-and-patterns round
- The headline constraints are a sound data model, correctness, and clean extensible code
- Prompts lean practical and enterprise: a scalable REST API, a Tiny URL, multi-tenant data
- Database and schema design are half the high-level round and probed directly
- UML relationships and applied design patterns are a full, separately graded surface
The SAP angleHow to approach it in the room
The two surfaces want different opening moves. Run the web-scale playbook where a data model or a class diagram is being graded, and you read as off-target fast. The split below is what an SAP-tuned answer looks like against the reflex that misfires.
Reads as strong at SAP
- In the high-level round, designs the database schema explicitly, choosing keys, indexes, and normalization on purpose
- Handles concurrency with the named levers the prompt invites: rate limiting, load balancing, horizontal scaling, queueing
- Can drop into the mechanism: how a REST request is routed, how microservices talk, why this datastore
- In the low-level round, models entities and relationships first, getting Association, Aggregation, and Composition right
- Applies a design pattern only where it removes a real branch and can place it in a concrete scenario
- Writes clean, readable, extensible classes and names the seam where the next requirement will land
Reads as off-target
- Leaves the database as a box labeled "a NoSQL store" and never designs the schema the prompt asked for
- Optimizes for a viral spike and a global cache when the load is steady enterprise traffic
- Draws a plausible architecture but cannot explain how the request flows through it
- Starts the low-level prompt by typing fields and getters before modeling responsibilities and relationships
- Names Singleton or Factory as a reflex, then defends a pattern the problem never needed
- Builds a rigid class hierarchy so the obvious extension forces edits across everything already written
The SAP angleThe worked designs in this section
Because SAP's design bar splits across two surfaces rather than converging on one canonical prompt, this section carries a worked design for each. The high-level design teaches the enterprise-tilted round from the API and schema through the scaling levers, and the low-level design teaches the modeling-and-patterns round from the domain classes through applied patterns. Build both carefully once and the moves transfer to the range of prompts each surface throws.
Design a Scalable REST API
The high-level round worked end to end with SAP's enterprise lens. A buildable API prompt goes from requirements through the database schema and the concurrency levers (rate limiting, load balancing, horizontal scaling, queueing). Then come the multi-tenancy and data-isolation concerns that separate an enterprise design from a consumer one. Practice it here and the same reasoning carries to the Tiny URL, news-feed, and N-concurrent-requests prompts.
Low-Level Design and Design Patterns
The modeling-and-patterns round worked in full. Turn a concrete prompt like a file system or a parking lot into clean classes, and get Association, Aggregation, and Composition right in the UML. Then place the creational patterns (Singleton, Factory) plus Observer and Strategy where they remove a real seam. This is the surface most candidates under-prepare, and the one that carries clean-code credit.
Common questions
Does SAP have a system design interview?
Yes, though it is lighter on raw scale than a FAANG round and split across two surfaces. Experienced-hire loops (roughly T2 and above on SAP's T1 to T5 ladder) carry a real design block, commonly a Java-plus-high-level-design round. Early-career and campus loops keep design lighter and sometimes fold it into a coding follow-up. The high-level surface is enterprise-tilted, a scalable REST API, a Tiny URL, a news feed, with the database design probed directly. Many candidates don't expect the second surface, low-level design and design patterns. It means modeling a file system or a parking lot as clean classes and placing the creational patterns in a real scenario.
What system design questions does SAP ask?
On the high-level side, recurring prompts include a Tiny URL with its HLD, database design, and heavy request volume. Another is an API that can handle N concurrent requests, with rate limiting, load balancing, horizontal scaling, and queueing as the follow-ups. Add a news feed or a Netflix-style streaming system, and model-plus-API design for concrete records like student data. Interviewers also probe internals such as how a REST request is routed and how microservices communicate. On the low-level side, there are three signature prompts. Draw the UML for a file system using Association, Aggregation, and Composition. Design a parking lot or vending machine as clean classes. Apply design patterns, with a reported heavy focus on the creational family.
How much scale and distributed-systems depth does SAP expect?
Less than a web-scale company, and more grounded. SAP wants the standard scaling levers: rate limiting, load balancing, horizontal scaling, and queue-based request handling. Reason honestly about sustained enterprise load instead of planning for a viral spike. A sound database schema and a clear read on how the request flows carry more weight than raw scale. On cloud and BTP teams, so do the enterprise concerns of multi-tenant data isolation and GDPR-style deletion. Depth scales with level: senior and experienced-hire candidates are expected to drive scalability, failure handling, and trade-offs without being pulled there.
Are design patterns really part of the SAP interview?
Yes, and this is where under-prepared candidates get caught. Multiple accounts describe a dedicated low-level design and patterns thread. The heavy focus is the creational patterns (Singleton and Factory), with Observer and Strategy close behind. The demand is consistent: apply a pattern to a real scenario instead of defining it. The same round tests object-oriented relationships directly, most memorably by asking for a file-system UML using Association, Aggregation, and Composition. Prepare patterns as tools you can place where they remove a real branch, and practice modeling a domain in clean, extensible classes, because that is the credit this surface pays out.
Key Takeaways
- ✓SAP design has two surfaces: an enterprise-tilted high-level round and a distinct low-level design-and-patterns round. Prep by knowing which one you're in instead of reaching for a single reference architecture.
- ✓The high-level round rewards a sound database schema and clean request handling over raw traffic. Recurring prompts are a scalable REST API, a Tiny URL, and a news feed, with concurrency handled through rate limiting, load balancing, scaling, and queueing.
- ✓The low-level design and patterns surface is the under-prepared signature. Expect a file-system UML using Association, Aggregation, and Composition, a parking-lot-style modeling prompt, and the creational patterns applied to a real scenario.
- ✓The enterprise lens matters on cloud and BTP teams. Multi-tenant data isolation, GDPR-style deletion, and SAP HANA or OData awareness signal fit. They're a bonus on top of a solid design.
- ✓Two worked designs carry the section, a scalable REST API and a low-level design with patterns. Build both once, narrate the trade-offs out loud, and the reasoning transfers to the range of prompts each surface throws.
SAP interview guideKnow what SAP asks before you walk in.
16 coding · 2 system design · 35 behavioral questions
Get their questions first.
InterviewLegend is independent and not affiliated with or endorsed by any company it covers.