ICICI Lombard: Senior Backend Engineer (Golang)

Answer:

In Go, modularity is achieved through proper package management and the use of interfaces.

• Clean Architecture: I separate the application into layers: Handlers (HTTP/gRPC), Use Cases (Business Logic), and Repositories (Data Access).
• Dependency Injection: Rather than tightly coupling components, I define interfaces for repositories and third-party services, and inject them into the Use Cases. This makes the code highly modular and testable.

  // Example of Dependency Injection
  type PolicyRepository interface {
      Save(ctx context.Context, policy Policy) error
  }
  
  type PolicyService struct {
      repo PolicyRepository
  }
  
  func NewPolicyService(r PolicyRepository) *PolicyService {
      return &PolicyService{repo: r}
  }

• Package Layout: I group files by domain (e.g., /motor, /claims, /policies) rather than by type (e.g., all controllers in one folder). This follows Domain-Driven Design (DDD) principles.

Answer:

When integrating with external or legacy systems, I assume they can fail or be slow.

• Timeouts: Use Go's context.WithTimeout for every outgoing HTTP/gRPC request to prevent our goroutines from hanging indefinitely.

  // Example: 5-second timeout for external API call
  ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
  defer cancel()
  
  req, _ := http.NewRequestWithContext(ctx, "GET", "https://blaze.api/legacy", nil)
  resp, err := http.DefaultClient.Do(req)

• Circuit Breaker: Implement a circuit breaker (like Netflix Hystrix or go-resiliency) to stop sending requests if the legacy system is down, allowing it time to recover and serving a fallback response to the user.
• Retries with Exponential Backoff: For transient errors (e.g., HTTP 503), implement retries with increasing delays.
• Idempotency: Ensure the APIs we call (or expose) are idempotent, especially for financial transactions like premium payments, so retrying a request doesn't result in double-charging.

Answer:

• Schema Design: I would normalize the data into tables like Users, Vehicles, Policies, and Payments. A Policy table would have foreign keys to User and Vehicle.
• Indexing: Add B-Tree indexes on frequently queried columns, such as user_id, vehicle_registration_number, and policy_status.
• Read Optimization: For heavy read operations (like fetching policy details for a dashboard), I would introduce Redis as a caching layer (Cache-Aside pattern). If a user views their policy, we check Redis first; on a miss, we query MySQL and store the result in Redis with a TTL.
• Transactions: For issuing a policy, we must write to Policies and Payments simultaneously. I would wrap these in a MySQL transaction with READ COMMITTED or REPEATABLE READ isolation to ensure ACID compliance.

Answer:

TDD involves writing the test before the actual implementation (Red-Green-Refactor).

• Interfaces for Mocking: I define interfaces for any external dependency (e.g., Database interface, EmailSender interface).
• Table-Driven Tests: Go's idioms heavily favor table-driven tests. I create a slice of anonymous structs defining the input, expected output, and expected error, and iterate through them using t.Run().

  func TestCalculatePremium(t *testing.T) {
      tests := []struct {
          name     string
          age      int
          expected int
      }{
          {"Young driver", 20, 1500},
          {"Experienced driver", 35, 800},
      }
  
      for _, tt := range tests {
          t.Run(tt.name, func(t *testing.T) {
              result := CalculatePremium(tt.age)
              assert.Equal(t, tt.expected, result)
          })
      }
  }

• Mock Generation: I use gomock or manually write mock structs that implement the interfaces to isolate the business logic during testing.
• Coverage: I run go test -cover to ensure the critical business paths are covered, particularly for complex logic like insurance premium calculations.

Answer:

Since the JD mentions multiple systems (Blaze, legacy IL systems, React frontend), a centralized auth mechanism is required.

• Single Sign-On (SSO): I would use OAuth 2.0 or OIDC (OpenID Connect). The user authenticates once via an Identity Provider (IdP).
• JWT (JSON Web Tokens): The IdP issues a JWT. The React frontend sends this JWT in the Authorization: Bearer header to the Go backend.
• Stateless Verification: The Go backend can verify the JWT signature using the IdP's public key without needing to do a database lookup for every request.
• Role-Based Access Control (RBAC): The JWT payload can include claims like role: admin or role: user. In Go, I would write a middleware function that checks the JWT validity and ensures the user has the required role to access the specific API route.

Answer:

• Concurrency: Utilize Goroutines to process independent tasks in parallel (e.g., fetching user profile and policy documents simultaneously). Use sync.WaitGroup to synchronize them.

  var wg sync.WaitGroup
  wg.Add(2)
  
  go func() {
      defer wg.Done()
      fetchUserProfile()
  }()
  
  go func() {
      defer wg.Done()
      fetchPolicyDocuments()
  }()
  
  wg.Wait() // Wait for both concurrent tasks to finish

• Connection Pooling: Ensure the database connection pool (sql.DB) is properly configured (SetMaxOpenConns, SetMaxIdleConns) to prevent exhausting database connections or spending too much time establishing new ones.
• Profiling: Use Go's built-in pprof tool to identify CPU bottlenecks and memory leaks (e.g., identifying goroutine leaks or excessive memory allocations).
• Avoid Reflection: Reflection in Go (like using the encoding/json package extensively on dynamic payloads) is slow. Where possible, use code generation (like easyjson) or avoid interface types.

Answer:

(This is a cultural/architectural question based on their stack).

Both have their places. PHP/Laravel is excellent for rapid application development, monolithic structures, and server-side rendering. However, as an application scales, Go shines due to its static typing, incredibly low memory footprint, and native concurrency model.

In a microservices architecture, it makes sense to use Go for high-throughput, compute-intensive APIs (like processing thousands of motor insurance claims or premium calculations concurrently), while PHP might still serve the legacy admin portals. Communication between them can happen via REST APIs or message queues like Kafka/RabbitMQ.

Answer:

• Goroutines vs Threads: Goroutines are user-space threads managed by the Go runtime, not the OS. They are extremely lightweight (starting at ~2KB of stack space compared to 1-2MB for OS threads), meaning you can spawn hundreds of thousands of them. They are multiplexed onto a smaller number of OS threads by the Go scheduler (M:N scheduling).
• Preventing Race Conditions: A race condition occurs when multiple goroutines access the same memory concurrently and at least one is writing. To prevent this, I use the sync.Mutex (or sync.RWMutex for read-heavy workloads) to lock critical sections. Alternatively, following Go's proverb: "Do not communicate by sharing memory; instead, share memory by communicating", I use channels to safely pass data between goroutines without explicit locking. I also religiously use the -race flag (go test -race or go build -race) during development to catch issues early.

  type SafeCounter struct {
      mu sync.Mutex
      v  map[string]int
  }
  
  func (c *SafeCounter) Inc(key string) {
      c.mu.Lock()
      // Lock so only one goroutine at a time can access the map c.v.
      c.v[key]++
      c.mu.Unlock()
  }

Answer:

Since ACID transactions don't span across multiple microservices databases, we have to rely on Eventual Consistency.

• Saga Pattern: I would implement the Saga pattern. It's a sequence of local transactions. Each local transaction updates the database and publishes an event or message to trigger the next local transaction in the saga.
• Compensating Transactions: If a step fails (e.g., the payment succeeds but the policy issuance fails), the saga executes a series of compensating transactions that undo the changes made by the preceding local transactions (e.g., issuing a refund).
• Implementation: This can be orchestrated via a central controller (Orchestration-based Saga) or through decentralized events published to a message broker like Kafka or RabbitMQ (Choreography-based Saga).

Answer:

Insurance deals with PII (Personally Identifiable Information) and financial data, so security is paramount.

• Encryption in Transit & at Rest: All API communication must be over HTTPS/TLS 1.2+. Sensitive database columns (like bank accounts or PAN numbers) should be encrypted at rest using a Key Management Service (AWS KMS or HashiCorp Vault) and AES-256-GCM.
• Data Masking: When returning data to the frontend or writing to logs, sensitive information should be masked (e.g., logging XXXX-XXXX-XXXX-1234 instead of a full credit card number).
• Input Validation & Parameterized Queries: Always validate incoming payloads against a strict schema (e.g., using Go's validator package) and use parameterized queries (via database/sql or an ORM like GORM) to prevent SQL injection.
• Rate Limiting & WAF: Implement IP-based and User-based rate limiting to prevent brute-force attacks and DDoS, alongside a Web Application Firewall.

Answer:

The JD specifically asks for this. To build reusable libraries in Go:

• Keep it focused (Single Responsibility): A library should do one thing well. For example, creating a centralized logger package or a metrics package that standardizes how all IL microservices report data.
• Design around Interfaces: Accept interfaces and return structs. This allows consumers of the library to mock the library easily in their own unit tests.
• Versioning and Dependency Management: Extract the reusable code into its own Git repository and tag it using Semantic Versioning (v1.0.0). Other projects can import it via Go Modules. Ensure backward compatibility; if introducing breaking changes, bump the major version (v2).
• Documentation: Write clear GoDoc comments for all exported functions and provide a README.md with usage examples.

Answer:

• Execution Plan (EXPLAIN): First, I run EXPLAIN on the slow query to see if it's doing a full table scan or using an index.
• Indexing: Add B-Tree indexes to columns used in WHERE, JOIN, and ORDER BY clauses. If querying multiple columns together frequently, create a Composite Index (remembering the left-most prefix rule).
• Avoid N+1 Queries: In application code, ensure we aren't running a query inside a loop. Use IN (...) clauses or JOINs to fetch related data in a single batch.
• Archiving / Partitioning: In insurance, old expired policies might not be accessed often. We can partition the table by date or archive old records to a data warehouse to keep the hot table small and fast.
• Read Replicas: Route all SELECT queries to read-replicas, freeing up the primary master database for INSERT/UPDATE/DELETE operations.

Answer:

• CORS: Since the React app (e.g., portal.icicilombard.com) might be hosted on a different domain or port than the Go API (e.g., api.icicilombard.com), the browser enforces the Same-Origin Policy. I would configure the Go backend's CORS middleware to explicitly allow the React app's origin, specifying allowed methods (GET, POST, PUT) and headers (Authorization, Content-Type).
• BFF (Backend-for-Frontend) Pattern: Instead of making the React app aggregate data from 5 different microservices, I would build a Go aggregation layer (BFF) that fetches the data concurrently, formats it exactly how the UI needs it, and returns a single JSON payload. This reduces client-side latency and battery drain on mobile devices.

Answer:

• Statelessness: Design the Go application to be completely stateless. Session data should live in Redis, not in application memory. This allows us to spin up multiple instances of the Go app behind a load balancer without worrying about sticky sessions.
• Health Checks: Expose /healthz and /readyz endpoints. Kubernetes or the Load Balancer uses these to know if the application is ready to accept traffic or if it needs to be restarted.
• Observability:
  • Logs: Use structured JSON logging (e.g., using slog or zap) so logs can be easily parsed by ELK/Datadog.
  • Metrics: Expose Prometheus metrics (CPU, memory, HTTP request durations, error rates).
  • Tracing: Implement Distributed Tracing (OpenTelemetry/Jaeger) by passing a trace ID through the context. When a request hits multiple microservices, the trace ID allows us to visualize the entire path and find the exact bottleneck.

Answer:

The JD requires "Proficient understanding of code versioning tools."

• Branching Strategy: I typically use Trunk-Based Development or GitHub Flow. Main branch is always deployable. We create short-lived feature branches, open Pull Requests (PRs), and merge back to main quickly.
• Code Reviews & CI/CD: A PR must be reviewed by at least one other engineer. I set up GitHub Actions / GitLab CI to automatically run go fmt, golangci-lint, and go test on every push. The PR cannot be merged if the build or tests fail.
• Merge vs Rebase: I prefer rebasing my feature branch onto the latest main before merging to keep a clean, linear commit history without unnecessary merge commits.