Architecture & Documentation

Identification is claiming who you are (a login or user id). Authentication is proving that claim (password, token, biometrics). Authorization is deciding what the authenticated identity may do. The order is fixed — identify, authenticate, then authorize each action against permissions.

Client-server splits software into a client that requests a service and a server that fulfils it over a network. A three-tier app separates a presentation tier (UI), an application-logic tier, and a data tier, each independently scalable.

A layered architecture stacks code into horizontal layers, each with one job: presentation, business logic, data access, and the database. A layer calls only the layer below it, so dependencies point one way and each layer stays testable alone.

A monolith is one deployable application where all modules share a process and usually one database — simple to build and deploy, but hard to scale or change in parts. Microservices split the system into independently deployable services, each owning its data and communicating over the network — flexible, at the cost of distributed-system complexity.

The analyst hands over the views that pin down what to build: a component diagram (the parts), sequence diagrams (how a scenario flows), the data model (entities and relationships), and the API contracts. Each answers a different question.

RBAC (role-based) grants permissions through roles a user is assigned. ABAC (attribute-based) decides access from attributes of the user, resource, and context — finer-grained but more complex. Least privilege grants only the minimal permissions needed, shrinking the blast radius.

An API Gateway is one entry point that routes requests and adds cross-cutting concerns: auth, rate limiting, aggregation, versioning. A load balancer only spreads traffic at the network level. A BFF (backend-for-frontend) targets one client type.

Cache where reads repeat and data changes slowly: a backend API cache (proxy or in-memory), and a client-side cache for per-user data. Invalidate with a TTL and/or event-based invalidation, where a write refreshes affected keys. Account for a cold versus warm cache. The trade-off is latency against staleness.

A monolith is simpler to build, deploy, and test — in-process calls, one transaction boundary — but it scales as a whole and grows brittle. Microservices give independent deployment, per-service scaling, and team autonomy, at the cost of network latency, distributed transactions, and heavier ops. Choose a monolith early; switch when scale, team size, or releases demand it.

Split by business capability or bounded context, so each service owns one cohesive area and its data. A boundary is wrong when a use case needs a chatty chain of services, two services share one transactional write, or they always deploy together.

Independence means a service can change and ship on its own across four axes. Code: its own repo, no shared build. Data: its own database, via its API only. Deploy: ships without redeploying others. Release: features go live behind a versioned API.

An HLD (high-level design) is an architecture-level description of how a system will be built, for architects, leads, and stakeholders to align on the solution before detailed design. It contains the major components, integrations and data flows, the architecture style, key non-functional decisions, and external dependencies. It stays intentionally shallow; the low-level design adds implementation detail.

For: independent deploys, per-service scaling, and team autonomy when the monolith blocks releases. Against: 15 services add network calls, distributed transactions, and ops load for a small team. Strangler: extract one or two loose services first.

Core documentation artifacts are: a business-process description; user scenarios; brief statements of business tasks; the database structure; data-flow, integration, and service-interaction diagrams; external integrations; own API descriptions with versioning; authentication/authorization/identification; and role/permission matrices.

Common styles are the monolith (one deployable unit), microservices (small independent services), SOA (coarse services on a shared bus), event-driven (react to events), and serverless (on-demand functions). Each trades simplicity for scalability.

CQRS (Command Query Responsibility Segregation) splits the write side (commands) from the read side (queries). It pays off when reads and writes differ in load or shape. Its cost is a read model synced asynchronously, bringing eventual consistency.

Event Sourcing stores state as an append-only log of change events, not the latest snapshot. State is rebuilt by replaying events, giving a full audit trail. What it makes hard: querying, schema evolution, and corrections via compensating events.

No, the ESB (enterprise service bus) is not the only difference. SOA uses coarse services on a central bus. Microservices are fine-grained, each owning its data and talking point-to-point, so they differ in granularity and data ownership.

Behind a load balancer, persist each request to a durable queue before acknowledging, then process async so an outage never loses work. Prevent double-charges with a per-payment idempotency key. Replicate the datastore and queue, the bottlenecks.

An AIS (automated information system) collects, stores, processes, and delivers an organisation's information. In ГОСТ 34 terms it splits into functional subsystems, by business function, and supporting subsystems: hardware, software, and data.