O que é o Ascendon em uma frase?
O Ascendon é uma plataforma de BSS digital em nuvem (SaaS) da CSG, multi-tenant e executada em AWS, que oferece módulos de catálogo, atendimento, billing, rating/charging e reporting para venda e cobrança de serviços digitais e telecom.
Quais são os principais módulos do Ascendon e o papel de cada um?
Customer Care: portal para CSR gerenciar contas, assinaturas, cobranças e tickets; Studio: gestão de catálogo de produtos/ofertas e regras de elegibilidade; Billing/Core Billing/ARM: cálculo de faturas, ciclos de billing, descontos, impostos e integração contábil; ARC: rating e charging em tempo real e batch; Reporting: relatórios de negócio e exportações; Configuration/Security: settings de BU, integrações, usuários e permissões.
O que significa dizer que o Ascendon é multi-tenant?
Multi-tenant significa que uma única plataforma lógica serve vários clientes (tenants), com dados segregados por business unit ou tenant; a infraestrutura é compartilhada (otimizando custos e escala), mas as regras de acesso garantem isolamento lógico e segurança entre clientes distintos.
Qual o papel do ARC (Ascendon Rating and Charging) na solução?
ARC é o domínio de rating/charging do Ascendon, composto por vários microserviços cloud-native em AWS, responsáveis por receber eventos de uso, enriquecer, tarifar em tempo real ou batch, aplicar regras de charging e disponibilizar resultados para billing e relatórios.
Como você resumiria a arquitetura do Ascendon do ponto de vista técnico?
É uma plataforma SaaS cloud-native em AWS, multi-tenant, baseada em microserviços para domínios como Customer Care, Studio, Billing e ARC, com APIs REST, bancos relacionais (SQL Server) e integrações externas via serviços e eventos, operando em múltiplas regiões e zonas de disponibilidade para alta disponibilidade e escala.
Quais ambientes típicos existem em uma implantação Ascendon?
Normalmente existem ambientes de QA/PRF (teste e performance), STG (staging), SBX/DEV (sandbox e desenvolvimento) e PRD (produção), distribuídos em diferentes regiões AWS, cada um com endpoints de serviços, metadata e interfaces (Customer Care, Studio) próprios.
Em alto nível, como o Ascendon suporta o ciclo de vida do cliente de telecom?
Studio define produtos/ofertas e regras; canais de venda integram via APIs para criar assinaturas; Customer Care gerencia contas, alterações e suporte; ARC calcula cobranças de uso em tempo real; Billing consolida eventos e recorrências em faturas com impostos e descontos; Reporting e integrações financeiras alimentam GL e análises.
Quais são as principais responsabilidades do Senior Software Development Engineer para Ascendon?
Projetar, analisar, codificar, modificar e suportar aplicações Ascendon; construir sistemas altamente disponíveis, escaláveis, resilientes e de fácil manutenção; automatizar tarefas com scripts/packaging; trabalhar em equipe agile; apoiar ambientes customer-facing (incluindo troubleshooting e monitoramento) e participar de on-call conforme necessário.
Quais competências técnicas principais a vaga explicita?
C#, .NET e ASP.NET Core (incluindo testes com xUnit); SQL Server com foco em modelagem de schema e queries eficientes; experiência com AWS (infraestrutura de nuvem e serviços gerenciados); familiaridade com Terraform (IaC), Git e pipelines de CI/CD; e alguma familiaridade com uso de AI no ciclo de desenvolvimento.
Que habilidades não técnicas a vaga enfatiza?
Trabalho em equipe em ambiente ágil, colaboração e comunicação em inglês, mentalidade de aprendizado contínuo, participação em code/design reviews, atitude proativa para resolver problemas em produção e disposição para aprender com o time e compartilhar conhecimento.
Como você explicaria SOLID em poucas frases para o contexto da vaga?
SOLID é um conjunto de princípios de design orientado a objetos (SRP, OCP, LSP, ISP, DIP) que ajudam a construir serviços .NET mais coesos, desacoplados e testáveis. No contexto da vaga, aplicar SOLID em APIs, serviços de domínio e camadas de acesso a dados facilita manutenção, testes automatizados e evolução do Ascendon sem grandes refactors arriscados.
O que significa construir sistemas ‘altamente disponíveis, escaláveis e resilientes’ na prática?
Altamente disponíveis: rodar em múltiplas zonas/regiões com health checks, auto-restart e failover; escaláveis: permitir scaling horizontal (novas instâncias) com balanceamento de carga e padrões sem estado; resilientes: implementar retries, timeouts, circuit breaker, isolamento entre componentes e boa observabilidade para detectar e recuperar de falhas rapidamente.
Como você explicaria para o entrevistador a arquitetura de um microserviço .NET típico que você escreveria para o Ascendon?
Controller/API mínima recebendo requisições REST; camada de aplicação/orquestração contendo casos de uso; camada de domínio com entidades e regras de negócio; infraestrutura implementando repositórios, clientes HTTP e integração com mensageria; DI configurando todas as dependências; testes unitários para domínio e testes de integração para endpoints principais.
Quais boas práticas você aplicaria ao criar uma API REST em ASP.NET Core para o Ascendon?
Seguir convenções REST (verbs, recursos e códigos HTTP adequados), validação model-state com respostas 400 claras, uso de DTOs específicos para entrada/saída, versionamento de API, autenticação/autorização consistentes, logging estruturado e correlação de requisições, paginação e filtros para resultados grandes e documentação via OpenAPI/Swagger.
Como você garante testabilidade no seu código C#/.NET?
Separando lógica de negócio de infraestrutura, usando interfaces e DI para dependências externas, evitando static acoplado, mantendo métodos pequenos e focados, escrevendo testes unitários com xUnit para regras de negócio, usando fakes/mocks para externalidades (banco, HTTP, filas) e mantendo boundaries claros entre camadas.
Que tipo de testes você priorizaria para serviços que suportam Ascendon em produção?
Uma base forte de testes unitários para regras de negócio e cálculos críticos (billing, rating, descontos), testes de integração para rotas e interações com banco/serviços, alguns testes end-to-end para fluxos-chave de cliente, além de smoke tests automatizados para validar o deploy em cada ambiente antes de liberar tráfego.
Como você descreveria um bom pipeline de CI/CD para um serviço .NET do Ascendon?
Pipeline acionado a cada push/PR, executando build, testes unitários, análise estática e geração de artefatos (imagens Docker ou pacotes). Em seguida, pipeline de CD faz deploy automatizado para ambiente de teste, roda smoke tests, e depois realiza deploy controlado para produção (blue-green ou canary), com rollback automatizado e métricas monitoradas.
Na modelagem de dados de billing, quais entidades básicas você considera?
Contas (Account/BillingAccount/ResponsibleParty), Assinaturas/Contratos (Subscription/Contract), Produtos/Ofertas (Product/Offer), Faturas (Invoice), Itens de Fatura (InvoiceItem), Pagamentos (Payment), Ajustes (Adjustment/Credit/Debit) e possivelmente uma camada de eventos de uso/tarifação ligada a essas entidades.
Como você relacionaria Invoice e InvoiceItem em SQL Server?
Criaria uma tabela Invoice com chave primária (InvoiceId) e colunas de cabeçalho (AccountId, período, vencimento, status, totais) e uma tabela InvoiceItem ligada por chave estrangeira InvoiceId, contendo descrição, referência ao produto/oferta, quantidade, preço unitário, impostos, descontos e valor total. Índices suportariam consultas por AccountId, datas e status.
Que tipos de queries são comuns em um contexto de billing?
Listar faturas abertas por cliente e faixa de datas, obter histórico de faturas de um cliente, detalhar itens de uma fatura, agregar receita por produto/plano/período, identificar inadimplência por segmento ou região e localizar quickly uma fatura específica (por ID ou número) para atendimento de suporte.
Como você abordaria problemas de performance em queries SQL Server?
Primeiro analisaria o plano de execução para ver scans desnecessários, índices não utilizados e joins caros; revisaria índices (criação de índices compostos, cobertura de filtros frequentes), verificaria estatísticas desatualizadas, reescreveria condições para serem SARGable, avaliaria particionamento para tabelas grandes e monitoraria locking/latches em cenários concorrentes.
O que é importante considerar ao projetar um schema multi-tenant em SQL Server?
Sempre incluir uma coluna de TenantId ou BusinessUnitId em tabelas de negócio, garantir que todas as queries filtrem por tenant, usar índices que incluam o tenant na chave, evitar vazamento de dados entre tenants em joins e views, e eventualmente separar alguns tenants grandes em bancos/instâncias distintos se requisitos de isolamento e escala exigirem.
Como você descreveria um deploy de serviço .NET em AWS com alta disponibilidade?
Empacotar o serviço em contêiner (Docker), rodar em ECS/EKS atrás de um Application Load Balancer, configurar Auto Scaling em múltiplas AZs, usar RDS SQL Server multi-AZ como banco, armazenar configurações sensíveis em Parameter Store/Secrets Manager, habilitar health checks no ALB, logs centralizados em CloudWatch e métricas/alarms para latência, erros e uso de recursos.
Que componentes AWS você esperaria ver em torno de um serviço Ascendon?
Serviços de compute (ECS/EKS/EC2), balanceadores (ALB/NLB), RDS para SQL Server, S3 para storage de arquivos/logs ou relatórios, CloudWatch para logs/métricas/alarms, possivelmente SQS/SNS/Kinesis para mensageria/eventos e integrações com IAM para segurança e controle de acesso.
