Design a good-till-triggered order service
PremiumBackend systemMedium
- GTT orders
- Trigger evaluation
- Kafka
Quick answer
This backend system interview question asks you to design a good-till-triggered order service. Aim for a design that meets its requirements at the stated scale, then explain its main components, data flow and trade-offs. Interviewers want to see how you scope the problem, size it and defend each choice.
The problem
Design a good-till-triggered (GTT) order service for a stock trading app: a user sets a trigger price and an order, and when the price crosses the trigger the service places that order on the exchange. GTTs live for up to a year. The hard part is that none of 1 million new GTTs a day may be lost or fired twice.
Exchange orders expire at the end of each trading day, so a long-lived order has to be held by the broker and placed only when its trigger fires.
What must a good-till-triggered order service do?
- Create GTTs: A user sets a symbol, a trigger price, and a limit order to place; it stays active for up to 365 days.
- Fire on trigger: When the last traded price crosses the trigger during market hours, the service places the order once through the order service.
How well must it do it?
- Never dropped: An acknowledged GTT is never lost, and a trigger always ends in exactly one order or a recorded failure.
- Trigger latency: The order is sent to the order service within 2 seconds of the crossing tick in normal markets.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- GTT orders
- Trigger evaluation
- Kafka
- Transactional outbox
- Idempotency
- OCO orders
How you’ll practise
- Requirements
- Estimate
- API and data
- High-level design
- Deep dives
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any backend system design round.
- Clarifies the requirements before drawing anything
- Uses a few numbers that actually change the design
- Draws a clear path from the client to storage
- Picks storage and caching with reasons, not by habit
- Explains what breaks first under load and how to fix it
- States trade-offs openly instead of claiming a perfect design
Questions people ask about this interview question
- Which design type is this question?
- It is a backend system question. You design a good-till-triggered order service and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Medium. Entry-level engineers can practise it, but it expects you to reason about requirements and trade-offs, not only list components.
- What should I cover first?
- Start with the requirements: what the system must do, how well it must do it and which numbers change the design. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team