Recruitment and knowledge question base. Filter, search and test your knowledge.
SOLID = 5 OO design principles. S (Single Responsibility): a class/module has one responsibility (one job) and should change for one reason. O (Open/Closed): extend without modifying existing code. L (Liskov Substitution): subtypes are safely substitutable (keep the contract). I (Interface Segregation): small focused interfaces, no unused methods. D (Dependency Inversion): depend on abstractions; inject implementations (DI).
REST exposes multiple resource endpoints and returns fixed response shapes, which can lead to over/under‑fetching. GraphQL exposes a single endpoint with a query language so the client asks for exactly the fields it needs, enabling nested fetches but adding schema/resolver complexity and different caching patterns.
The CAP theorem says that in a distributed system you can’t fully guarantee Consistency, Availability and Partition tolerance at the same time. When a network partition happens, the system must choose between staying consistent or staying available.
Common load‑balancing strategies include round‑robin, least connections, weighted variants, IP‑hash/sticky sessions, and consistent hashing. Load balancers can work at L4 (TCP/UDP) or L7 (HTTP) and use health checks to avoid unhealthy nodes.
Event‑Driven Architecture is a style where components communicate by publishing and reacting to events. Producers emit events to a broker and consumers handle them asynchronously, decoupling services and improving scalability at the cost of eventual consistency and harder tracing.
S: one responsibility per class (one reason to change); O: extend behavior without modifying existing code; L: subtypes must keep the contract of the base type; I: prefer small, focused interfaces; D: depend on abstractions, not concrete implementations (DI).
Idempotent means repeating the same request produces the same result/state (e.g., multiple PUTs set the resource to the same value). It matters for safe retries.
You want low coupling (modules depend on each other as little as possible) and high cohesion (a module’s code belongs together). That makes changes safer: fewer ripple effects and clearer responsibilities.
DTOs are shaped for transport/API, domain models are shaped for business rules. Keeping them separate reduces coupling between API and core logic and prevents leaking internal invariants or fields.
CQRS separates reads (queries) from writes (commands), often with different models optimized for each. It helps when read and write needs are very different, but adds complexity.
Cache-aside: app reads from cache, on miss loads from DB and populates cache; writes go to DB and cache is updated/invalidated. Write-through: writes go through the cache which also writes to DB, keeping cache in sync but adding write latency.
2PC gives atomic commit across services but is heavy and can block on failures. Sagas use a sequence of local transactions with compensating actions, trading strict consistency for availability and simpler scaling.
Accept an idempotency key from the client and store the result keyed by (user, key). If the same key is sent again, return the stored result instead of creating duplicates.
Prefer backward-compatible changes: only add optional fields, don’t rename/remove fields, and version events when you must break compatibility. Consumers should ignore unknown fields and handle missing fields safely.
Common strategies are token bucket and leaky bucket (or fixed/sliding window). You can enforce limits at the edge/API gateway, load balancer, or in the app (per user/IP), ideally close to the entry point.
Authentication answers “who are you?” (prove identity). Authorization answers “what are you allowed to do?” (permissions) after you’re authenticated.
Keep business logic in the center (domain/use cases) and talk to the outside world through ports (interfaces). Adapters implement those ports for DB, HTTP, queues, etc., so you can swap infrastructure without rewriting core logic.
Eventual consistency means different parts of the system may show different data for a short time, but they converge. To a user: “Your change is saved; it may take a few seconds to appear everywhere—refresh or wait.”
Offset pagination is simple (`page=10`) but can get slow on deep pages and can skip/duplicate items when data changes. Cursor pagination uses a stable “last seen” key, scales better, and is more consistent, but is more complex for clients and doesn’t support random page jumps well.
Version when you introduce breaking changes you can’t make backward compatible. Common strategies: version in the URL (`/v2/...`) or via headers/content negotiation. Prefer backward-compatible changes when possible (add optional fields).
An SLI is a measurable metric of service performance (e.g., availability, latency, error rate). It’s the number you track to understand reliability.
An SLO (Service Level Objective) is a target for an SLI (e.g., 99.9% availability). The error budget is the allowed “room for failure” (100% - SLO). Teams use it to balance shipping features vs improving reliability.
Averages hide tail latency: a few very slow requests can be invisible in the mean but painful for users. p95/p99 show how the slowest 5%/1% behave and help catch queueing and saturation issues.
Good alerts are actionable and user-impact focused (symptom-based), with clear severity and a runbook link. Avoid alert fatigue by reducing noisy alerts, using proper thresholds, grouping, and paging only on real incidents (use error budgets).
A blameless postmortem focuses on what happened and how to improve the system, not who to blame. It produces concrete action items (fixes, alerts, runbooks) and builds a culture where people report issues early.
A stateless service keeps request state outside the instance (e.g., in a DB/Redis), so any instance can handle any request. A stateful service keeps state in memory on a specific instance, which makes scaling and failover harder (you need sticky sessions or state replication).
NFRs describe how the system should behave, not what features it has. Examples: performance (p95 latency), availability, security, scalability, observability, and compliance. NFRs strongly influence architecture choices.
A bounded context is a boundary where a domain model and terms have one consistent meaning. It helps reduce coupling by preventing one “mega model” for everything, and it makes it clearer where to split teams, services, or modules.
A cache stampede happens when many requests miss the cache at the same time (often when an item expires), so they all hit the database. Mitigations: TTL jitter, “single flight”/locks per key, stale-while-revalidate, and warming critical keys.
Graceful degradation means the system still works in a reduced mode when parts fail (e.g., show cached data if recommendations are down). Design for it with timeouts, fallbacks, circuit breakers, feature flags, and clear user messaging for partial functionality.
CORS is a browser rule that controls which origins can read responses from your API via JavaScript. It’s not authentication and it doesn’t stop someone from calling your API from a server or tools like curl. You still need proper auth/authz and input validation on the server.
A reverse proxy sits in front of your application servers and forwards client requests to them. It’s commonly used for TLS termination, routing, load balancing, caching/compression, and sometimes rate limiting or WAF rules.
An ADR is a short document that records an architecture decision: the context, options considered, the decision, and its consequences. It’s useful because it preserves “why” something was chosen, helps onboarding, and reduces repeating the same debates months later.
Event sourcing stores state as a sequence of events (facts), and current state is rebuilt by replaying them into a projection. Benefits: audit trail, easy history, and time-travel/debugging. Trade-offs: higher complexity, event schema evolution, more moving parts (projections), and harder ad-hoc queries.
An anti-corruption layer is a translation boundary that protects your domain model from leaking concepts from a legacy/external system. You use it when integrating with something that has a different model or ugly API, so you keep your core clean and map data in one place.