Architecture Decision Lab

Примите решение. Посмотрите, что будет.

Каждый сценарий — реальная ситуация в команде. Выберите вариант — увидите последствия, компромисс и условия, при которых лучше был бы другой вариант.

Сценарии на английском языке.

Сценариев: 0 из 6

01 · Middle

An order is created and inventory and email must be told

The order service writes the order to PostgreSQL, then must tell the inventory service and trigger a confirmation email to the customer. At peak, about 200 orders per second are expected (an assumed figure). The email provider is sometimes slow or briefly unavailable. The team already runs a Kafka cluster.

Ограничения

Accepting an order must not depend on the email provider's speed.
The inventory notification for a confirmed order must not be lost.
The team has 4 people and does not want to add new infrastructure.

How should these notifications be delivered?

After saving the order, the order service calls inventory and email via REST, one after another.Write the order and an event row in an outbox table in the same transaction; a separate relay publishes it to Kafka, and the inventory and email consumers read independently.The order service publishes to Kafka directly after the transaction commits (no outbox).The inventory and email services poll a shared "tasks" table in the same database.

02 · Middle

Product catalogue: fast reads, but price changes must show quickly

The catalogue API is read-heavy: about 2000 reads per second, and only a few writes per minute (assumed figures). Product data lives in PostgreSQL, which is loaded at peak. A price change must be visible to customers in at most one minute. The team already uses Redis.

Ограничения

Price-change visibility delay of at most 1 minute.
Read load on the database must go down.
There is no time to maintain complex invalidation logic.

Which caching strategy fits these constraints best?

Cache-aside in Redis with a short 30-60 second TTL, delete the key on price update, and stampede protection for hot keys.A long TTL (for example 24 hours) and manual cache purging only.No cache; add indexes and tune the queries instead.Write-through cache: write to both database and cache on every update, with no TTL.

03 · Senior

Deploys are slow and the team wants microservices

A team of 5 runs a Spring Boot monolith; the code is split into modules, but boundaries between them are not enforced and there is one database. Deploys are slow because the CI pipeline runs all tests and every release is checked by hand. The team wants to move to microservices to fix the slow deploys. There is no platform or DevOps specialist.

Ограничения

Only 5 engineers and no dedicated platform team.
The main pain is deploy speed; there is no need for independent scaling.
The business cannot afford delays in new features.

What should the first step be?

Convert all modules into separate microservices at once.First fix the monolith's delivery pipeline: parallelize tests, automate release checks, enforce module boundaries in code (architecture tests); extract services only when a concrete reason appears.Extract a single module (for example notifications) as a separate service and see how it goes.Write all new features only as separate services and leave the monolith untouched.

04 · Senior

Moving money between two accounts held by different services

Accounts currently live in two separate services with separate databases: one for local accounts and one for external payment accounts. A user wants to move money from one to the other. In every case money must be neither lost nor created twice. The services talk over HTTP and network failures are possible.

Ограничения

Money must never be lost or duplicated.
Services and databases are separate, with no shared transaction manager.
Every step must be traceable for audit.

How should the transfer be organized?

Use two-phase commit (2PC / XA) to bind both databases into one distributed transaction.A saga: a debit step, then a credit step; if credit fails, compensate by reversing the debit. Each step uses an idempotency key and the saga state is stored durably.Keep both accounts in one service and one database and make the transfer an ordinary ACID transaction.Debit, then publish a fire-and-forget event; the receiving service credits it, with no acknowledgement awaited.

05 · Senior

A reporting dashboard slows the transactional database

An internal reporting dashboard runs heavy aggregation queries during business hours, and order transactions sharing the same PostgreSQL slow down. The transactional database is a single primary instance. Staff tolerate reports that are a few minutes old, but some managers want "today's sales" to be roughly fresh. The budget is limited.

Ограничения

Transaction latency must not be affected by reports.
Report data may be a few minutes stale.
The team has limited experience running additional systems.

How should the reporting load be separated?

Set up a read replica of the existing PostgreSQL and point the dashboard at it.Stream changes via CDC into a separate analytical store (for example a columnar one).Move the primary to a bigger instance (more CPU and RAM).Serve reports from files exported nightly.

06 · Architect

An LLM assistant that can change customer orders

The product team wants an LLM-based assistant that helps customers change their orders (address, quantity, cancellation). The backend already has APIs for these operations with validation and authorization rules. The model can sometimes misunderstand, or be manipulated by instructions hidden in user text (prompt injection). Order changes carry financial and customer impact.

Ограничения

A customer may only change their own orders.
A wrong or manipulated action must not cause harm.
Actions must be auditable and reversible where possible.

How should the assistant's ability to change orders be designed?

Give the model direct SQL or write access to the database so it can change whatever it decides.Tool calling: the model can only call narrow, typed tools (for example "change address"), parameters are validated against schemas, authorization is checked server-side using the user's session, and the change is executed only after user confirmation.Ship a read-only assistant first (order status, policies) and add change capabilities later.Skip the LLM and use a rules-based chatbot with menus, buttons and predefined flows.

Хотите научиться защищать такие решения в реальных проектах?

Посмотрите программы System Design и Solution Architecture или попробуйте case-интервью.

Case-интервью Программы