ਬੈਕ ਐਂਡ ਡਿਵੈਲਪਰਇੰਟਰਵਿਊ ਜਵਾਬ

ਮੈਂ REST ਦੇ ਸਿਧਾਂਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ: resources ਨਾਮ (ਨਾਉਂ) ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ (ਕਿਰਿਆਵਾਂ לא ਹੋਣ), URIs ਹਾਇਰਾਰਕੀਕਲ ਹੋਣ ਅਤੇ resource ਸੰਬੰਧ ਦਰਸਾਉਣ। HTTP ਮੈਥਡ ਸੇਮੈਂਟਿਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤੇ ਜਾਂਦੇ ਹਨ (GET = read, POST = create, PUT/PATCH = update, DELETE = remove)। ਮੈਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ API ਨੂੰ ਵਰਜ਼ਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ (/v1/) ਤਾਂ ਕਿ non-breaking ਤਬਦੀਲੀਆਂ ਸੰਭਵ ਹੋ ਸਕਣ। ਮੈਂ consistent response ਫਾਰਮੇਟ, error ਕੋਡ ਅਤੇ pagination ਪੈਟਰਨ ਡਿਜ਼ਾਇਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। ਮੈਂ ਦਸਤਾਵੇਜ਼ੀकरण ਲਈ OpenAPI/Swagger ਦੀ ਵਰਤੋਂ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। ਡਿਜ਼ਾਇਨ ਦੌਰਾਨ client ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਬਾਰੇ ਸੋਚਦਾ/ਸੋਚਦੀ ਹਾਂ — ਇੱਕ API ਜੋ ਤਕਨੀਕੀ ਰੂਪ ਵਿੱਚ ਠੀਕ ਹੋ ਪਰ ਵਰਤਣ ਲਈ ਮੁਸ਼ਕਲ ਹੋਵੇ, ਉਹ ਬੁਰਾ API ਹੈ। ਮੈਂ rate limiting, authentication ਅਤੇ input validation ਨੂੰ ਪਹਿਲ ਦਰਜੇ ਦੇ API concerns ਵਜੋਂ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ/ਰੱਖਦੀ ਹਾਂ.

ਮੈਂ schemas ਨੂੰ access patterns ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਇਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ — ਮੂਲ ਤੌਰ 'ਤੇ normalise ਕਰਦਾ/ਕਰਦੀ ਹਾਂ ਅਤੇ ਜਦੋਂ query performance ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ denormalise ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। ਮੈਂ ਇੰਡੈਕਸਾਂ ਨੂੰ ਸਟ੍ਰੈਟੇਜਿਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ: ਹਰ slow query ਲਈ EXPLAIN plan ਵੇਖਦਾ/ਵੇਖਦੀ ਹਾਂ, ਅਤੇ indexes ਨੂੰ selectivity ਅਤੇ query frequency ਦੇ ਆਧਾਰ 'ਤੇ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਮੈਂ N+1 queries ਤੋਂ ਬਚਾਉਣ ਲਈ data layer ਵਿੱਚ eager loading ਡਿਜ਼ਾਇਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। ਮੈਂ migrations ਨੂੰ ਧਿਆਨ ਨਾਲ ਲਿਖਦਾ/ਲਿਖਦੀ ਹਾਂ — ਜਿਥੇ ਸੰਭਵ ਹੋਣ, backwards-compatible changes ਅਤੇ breaking schema changes ਲਈ blue-green deployment ਰਣਨੀਤੀਆਂ। ਮੈਂ ਡੇਟਾ ਇੰਟੈਗ੍ਰਿਟੀ ਲਈ ਵੀ ਡਿਜ਼ਾਇਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ: foreign key constraints, not-null constraints ਅਤੇ check constraints ਨਾਲ consistency ਡੇਟਾਬੇਸ ਲੇਵਲ ਤੇ ਯਕੀਨੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ.

ਮੈਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ stateless services ਡਿਜ਼ਾਇਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ — ਸਟੇਟ ਡੇਟਾਬੇਸ ਜਾਂ cache (ਅਪਲੀਕੇਸ਼ਨ ਮੈਮੋਰੀ ਵਿੱਚ ਨਹੀਂ) ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਮੈਂ ਉਹ ਕੰਮ ਜੋ synchronous ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਉਹਨਾਂ ਲਈ async processing ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ (message queues: RabbitMQ, Kafka, SQS)। ਮੈਂ ਠੀਕ ਲੇਅਰ 'ਤੇ aggressive caching ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ: ਡੇਟਾਬੇਸ query results (Redis), computed aggregations ਅਤੇ static resources। ਮੈਂ APIs ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਇਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ ਕਿ ਉਹ horizontally scalable ਹੋਣ ਅਤੇ managed services (RDS, ElastiCache) ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ/ਦਿੰਦੀ ਹਾਂ ਜੋ ਅਲੱਗ ਤੌਰ 'ਤੇ scale ਕਰ ਸਕਣ। ਮੈਂ rate limiting ਅਤੇ backpressure ਹੇਲਿੰਗ ਯੋਜਨਾਵਾਂ ਵੀ ਰੱਖਦਾ/ਰੱਖਦੀ ਹਾਂ — services ਨੂੰ load ਹੇਠ ਸਹਿਜਤਾ ਨਾਲ degrade ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.

Authentication ਲਈ: OAuth 2.0 / OIDC ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ user auth ਲਈ, service-to-service ਲਈ API keys ਜਾਂ JWT। ਮੈਂ ਸਾਰੇ ਇਨਪੁਟ ਨੂੰ validate ਅਤੇ sanitise ਕਰਦਾ/ਕਰਦੀ ਹਾਂ — user input ਤੋਂ direct SQL ਬਣਾਉਣ ਤੋਂ ਬਚਦਾ/ਬਚਦੀ ਹਾਂ। ਮੈਂ abuse ਰੋਕਣ ਲਈ rate limiting ਅਤੇ throttling ਲਗਾਉਂਦਾ/ਲਗਾਉਂਦੀ ਹਾਂ। ਮੈਂ ਹਰ ਥਾਂ HTTPS/TLS ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ ਅਤੇ certificate validation ਨੂੰ enforce ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। ਮੈਂ least-privilege ਸਿਧਾਂਤ ਲਗੂ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ: ਹਰ service ਅਤੇ user ਕੋਲ ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦੇ permissions ਹੁੰਦੇ ਹਨ। ਮੈਂ privilege ਵਰਤੋਂ ਨੂੰ audit ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। ਮੈਂ CI ਵਿੱਚ dependencies ਨੂੰ vulnerabilities ਲਈ scan ਕਰਦਾ/ਕਰਦੀ ਹਾਂ (OWASP Dependency-Check, Snyk)। ਅਤੇ ਮੈਂ security events — failed authentications, privilege escalations ਆਦਿ — مرکزی ਤੌਰ 'ਤੇ log ਕਰਦਾ/ਕਰਦੀ ਹਾਂ ਲੈਣ ਵਾਲੀ ਨਿਗਰਾਨੀ ਲਈ.

ਮੇਰਾ ਸਿਧਾਂਤ ਹੈ ਕਿ errors ਨੂੰ log ਕੀਤਾ ਜਾਣਾ, ਵਰਗੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾਣਾ ਅਤੇ ਮਾਇਨੇ ਵਾਲੇ ਢੰਗ ਨਾਲ ਵਾਪਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੈਂ structured logging (JSON) ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ ਅਤੇ ਲੋਗ ਲੈਵਲ ਉਚਿਤ ਰੱਖਦਾ/ਰੱਖਦੀ ਹਾਂ ਤਾਂ ਜੋ ਲੋਗਾਂ ਨੂੰ query ਕੀਤਾ ਜਾ ਸਕੇ। ਮੈਂ distributed tracing ਲਾਗੂ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ (OpenTelemetry) ਤਾਂ ਜੋ requests ਨੂੰ ਸੇਵਾਵਾਂ ਦੇ ਅੰਦਰ follow ਕੀਤਾ ਜਾ ਸਕੇ। ਮੈਂ API ਵਿੱਚ error codes ਨੂੰ consistent ਤਰੀਕੇ ਨਾਲ define ਤੇ document ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। ਮੈਂ ਕੇਵਲ technical metrics (ਜਿਵੇਂ CPU) ਹੀ ਨਹੀਂ, error rate anomalies 'ਤੇ alerting ਸੈੱਟ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। microservice architectures ਵਿੱਚ, ਮੈਂ cascade failures ਰੋਕਣ ਲਈ circuit breakers (Resilience4j, Hystrix) ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ ਜਦੋਂ dependency degrade ਹੋਵੇ।

ਮੇਰਾ ਤਜਰਬਾ ਦੋਨਾਂ ਦੇ ਨਾਲ ਹੈ। Monoliths ਅਕਸਰ ਘੱਟ ਅੰਕਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: ਉਹ ਵਿਕਾਸ, ਟੈਸਟ ਅਤੇ ਡਿਪਲੌਯ ਕਰਨ ਲਈ ਸਧਾਰਣ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੂੰ microservices ਦੀ ਲੋੜ ਸਿਰਫ਼ ਉਸੇ ਵੇਲੇ ਪੈਂਦੀ ਹੈ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਖਾਸ scale ਜਾਂ ਟੀਮ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸੰਬੰਧੀ ਪਾਬੰਦੀਆਂ ਆਉਣ। ਜਦੋਂ ਮੈਂ microservices ਵੱਲ ਗਿਆ/ਗੀ, ਮੈਂ Strangler Fig pattern ਲਗਾਇਆ — ਇੱਕ ਕੰਮ ਕਰ ਰਹੇ monolith ਤੋਂ incremental ਤੌਰ 'ਤੇ services ਨਿਕਾਲਣ (extract) ਕੀਤਾ, big-bang decomposition ਨਹੀਂ ਕੀਤਾ। Microservices operational complexity ਵਧਾਉਂਦੀਆਂ ਹਨ (service discovery, distributed tracing, network failure modes, services ਵਿੱਚ data consistency ਆਦਿ) — ਮੈਂ ਇਹ complexity ਸਿਰਫ਼ ਤਦ ਹੀ ਗ੍ਰਹਿਣ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ ਜਦੋਂ ਫਾਇਦੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਹੋਣ।

ਮੈਂ business logic ਲਈ unit tests ਲਿਖਦਾ/ਲਿਖਦੀ ਹਾਂ ਜੋ ਆਇਸੋਲੇਸ਼ਨ ਵਿੱਚ ਹੋਣ (database ਅਤੇ external dependencies ਨੂੰ mock ਕਰਕੇ)। ਮੈਂ integration tests ਲਿਖਦਾ/ਲਿਖਦੀ ਹਾਂ ਜੋ ਇੱਕ ਅਸਲੀ (test) database ਦੇ ਖਿਲਾਫ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ — ਇਹ full request-response cycle ਨੂੰ ਚੈੱਕ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹ SQL errors, query performance ਮਸਲੇ ਅਤੇ data mapping ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪਕੜ ਲੈਂਦੇ ਹਨ ਜੋ unit tests ਮਿਸ ਕਰ ਸਕਦੇ ਹਨ। ਜਿੱਥੇ ਸੇਵਾਵਾਂ ਦੀਆਂ published APIs ਹੋਣ, ਮੈਂ contract testing (Pact) ਵਰਤਦਾ/ਵਰਤਦੀ ਹਾਂ। ਮੈਂ performance-critical endpoints ਲਈ load tests (k6, Locust) ਵੀ ਲਿਖਦਾ/ਲਿਖਦੀ ਹਾਂ। Test coverage ਕਦਰਯੋਗ ਹੈ ਸਿਰਫ਼ ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਜਦੋਂ tests ਅਸਲੀ ਫੇਲਿਯਰਾਂ ਨੂੰ ਪਕੜ ਸਕਣ।

ਮੈਂ RabbitMQ ਅਤੇ Apache Kafka ਵਰਤ ਕੇ event-driven systems ਡਿਜ਼ਾਇਨ ਕੀਤੀਆਂ ਹਨ। ਮੈਂ trade-offs ਨੂੰ ਸਮਝਦਾ/ਸਮਝਦੀ ਹਾਂ: at-least-once vs exactly-once delivery, consumer group patterns, dead letter queues ਅਤੇ message ordering guarantees। ਮੈਂ message schemas ਨੂੰ ਧਿਆਨ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ — production ਵਿੱਚ backwards-compatible schema evolution ਬਹੁਤ ਜਰੂਰੀ ਹੈ। ਮੈਂ idempotent consumers ਲਾਗੂ ਕਰਦਾ/ਕਰਦੀ ਹਾਂ ਤਾਂ ਜੋ duplicate messages ਨਾਲ data corruption ਨਾ ਹੋਵੇ। ਮੈਂ queue depth ਅਤੇ consumer lag ਨੂੰ ਮੁੱਖ operational metrics ਵਜੋਂ monitor ਕਰਦਾ/ਕਰਦੀ ਹਾਂ। Event-driven architectures ਵੱਡੀ scalability ਅਤੇ decoupling ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਇਨ੍ਹਾਂ ਲਈ disciplined schema management ਅਤੇ failure handling ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ.